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ABSTRACT 



The modem tactical commander has a flood of sensory and intelligence information 
at his disposal. A tool is required to sort that information, allowing the commander to 
choose the information that is most pertinent to the decisions he must make at that tune. 
This study is the preliminary work on the command and control woikstation of the future. 
The focus of this effort is in two areas. One is a user interface using multiple windows 
and a mouse controlled cursor. This interface allows the user to set up the display to give 
him the information he needs in a way that is easy for him to interpret. The second focus 
is preliminary work on a real-time display that presents the user with a three-dimensional 
picture of the situation. This initial display uses three resolutions to display large areas of 
Defense Mapping Agency Digital Terrain Elevation Data with near real time animation. 
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I. OVERVIEW 



A. THE COMMAND AND CONTROL WORKSTATION 

The amount of information that the modem day commander must assimilate is 
staggering. There are inputs from a multitude of sensors: NTDS, radars, sonar. There are 
situation reports, intelligence reports and messages of various types continually arriving. 
On top of tliis, the commander has at his disposal a database of intelligence information 
made up of charts and publications that cannot be quickly accessed. The commander 
needs a tool that gives him instant access to this information, presenting it in a way that 
allows him to quickly grasp the facts and make a decision. He should be able to easily 
manipulate the data to show only the information pertinent for the situation at hand and 
that data should be up to date and instantly intelligible. It should be easy to display new 
or amplifying information as situations change and evolve. 

This study is the preliminary work for the design and implementation of a tool to 
provide the commander easy access to command and control information, the Command 
and Control Workstation of the future (CCWF). The goal of this work is the 
development of the visualization tools and techniques required to build a prototype 
workstation with a flexible user-friendly interface and a real-time, three-dimensional 
display that possesses the characteristics described above. The CCWF is implemented on 
inexpensive workstations available in the Graphics and Video Laboratory of the 
Department of Computer Science at the Naval Postgraduate School. 

1. Discussion 

The graphical and computational power of low cost workstations can be 
utilized to build a effective system that meets or exceeds our goals for a command and 
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control workstation. Areas that we have explored are: networking between multiple 
workstations and mini-computers, the use of multiple windows to help provide an easily 
managed, user friendly interface, and a real time three-dimensional display. 

a. Color 

Due to expense, color graphics have not been utilized in the development 
of current command and control displays. The advent of inexpensive graphics 
workstations has made the use of color not only possible but a cost effective means to 
make the display easier for the user to interpret. The user must read and decode the 
textual information before he can extract the information he requires. With such 
systems, it is hard to find the particular bit of information needed from a screen full of 
text. TTie textual representation can be improved by coding the information. In coding, 
the original stimulus or information is converted to a new form and displayed 
symbolically. Coding can make the infonnation easier to find and interpret than direct 
representation. Current command and control displays use a special military symbology 
to represent information but do not use color as a coding medium. Color is an effective 
dimension of coding that has been shown to improve human response time. [Ref. 1] 
Color is particularly effective in searching tasks where one is scanning through data 
looking for information of a sp>ecific type, such as scanning a command and control 
display for enemy aircraft. With the dropping cost of color displays, it no longer makes 
sense to utilize only monochrome when the combination of current symbology with color 
can increase the effectiveness of our displays. Color will particularly improve 
performance for the monitor who has other tasks besides watching the scope. The radar 
operator whose job is tracking contacts on the radar screen knows what each contact is. 
Color wUl make it easier for the supervisor to occasionally glance at the screen and 
quickly comprehend the information presented. 
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b. Networking 

A command and control workstation has to rely heavily on networking. It 
has to handle several thousand contacts from tactical data systems such as NTDS, as well 
as entries from various intelligence sources. These contacts have to be continuously 
updated over the network to insure that the information that is displayed is as up to date 
as possible. 

The network can be used to allow multiple workstations to access a 
common database of intelligence and amplifying information that allows the user to 
display digitized intelligence photos or provide parameters on weapon systems and 
platforms. The displays can obtain and display fixed land based objects of interest like 
surface to air missile sites or targets for an air strike. This ability makes the workstation 
useful for planning and training purposes as well as command and control in the heat of 
battle. 

The network also has to handle any communication between die 
workstations. Along with an exchange of information at the system level, a mail system 
can help a user more effectively manage his time by evaluating an incoming message 
and informing the user that mail has arrived by displaying the message’s precedence and 
subject line. Tlie user can then, at his convenience, open a message window and examine 
his mail. 



c. Windows 

The user interface is an important design decision in any system, 
especially when designing a command and control workstation. The purpose of 
command and control workstations is to assist the user by displaying needed information 
quickly, in a manner that is easy to understand. The user interface needs to be easy to 
operate and quick to change, allowing the user to manipulate the display with a minimum 
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of fuss and bother. A technique that has become common on commercial workstations 
and personal computers is the use of windows. A window is simply a virtual display. One 
or more windows can be open and displayed on a computer monitor at one time. 
Operations that are fairly standard on all window systems allow the window to be moved 
about the screen and the size changed. The windows can be tUed so all windows can be 
seen or stacked where one window overlaps all or part of the other windows. Push and 
pop commands cause a window to be drawn on the bottom or top of the stack. Most 
window interfaces use a mouse controlled cursor to make these operations even easier 
but a "track ball" familiar to users of current naval command and control systems can be 
used with equal ease. Multiple windows allow the user to set up his display depending on 
the current situation and his particular preferences. This set up can be easily changed as 
the need of the user changes. A possible window set up for a command and control 
workstation might be: one small window displaying information such as time, own ship’s 
position, course and speed; two windows with two dimensional radar type displays, one 
set up with a short range showing surface tracks, the other long range air tracks; another 
window set up with a chart of the area showing map infoimation as well as contact 
infonnation; and finally a simulated three- dimensional view that gives the user a "real 
world" perspective on the situation. By using a mouse, amplifying infonnation can be 
shown on objects in any of the windows simply by pointing and clicking. As the situation 
changes, windows can be opened, closed, moved, and the size modified to form a display 
that presents the required information in a manner that can be easily understood and 
acted upon. 

d. Tliree-Dimensional View 

There is a saying that a picture is better than a thousand words. This is not 
only true because we can get more tlian a thousand words of information into one picture 
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but because a human user can extract the information quicker and easier. We have spent 
our whole lives evaluating situations in three -dimens ions. Every time we drive a car or 
walk across the street, our mind instantly evaluates what we see and determines tlte 
appropriate action. Up to now, that has not been possible in the command and control 
environment. We have relied on two dimensional displays and written status boards that 
present a picture of the situation that our mind must interpret before making a decision. If 
the information can be presented in the three-dimensional form that a user is used to 
dealing with, he can more intuitively grasp the situation and act accordingly. As usual, 
the science-fiction writers have lead the way for technology to follow. In the final battle 
scene of the movie "STAR WARS", the commanders coordinating the attack are all 
observing and making their decisions based on a large three-dimensional holographic 
display. Current tecluiology isn’t quite to that point yet but we can present excellent, 
real-time, three-dimensional animation on current graphics workstations. 

How useful can such a tlnee -dimensional display really be? The modem 
day commander has to keep thousands of facts and figures in his head about weapons 
platforms, sensors, weapons, effective ranges, what is on what ship, what planes have 
what capabilities, etc. He then has to apply this information to the current situation, 
picturing in his head the weapons envelopes relative to himself and other contacts. How 
much easier would it be if he could look at a three-dimensional representation showing 
contacts and selected weapons envelopes? He could almost instantly assess the situation 
and act. 

An amphibious landing is another instance where this three-dimensional 
view is valuable. Landing areas and boat lanes can be marked. By using a digital terrain 
database, the land can be accurately displayed. Landmarks, friendly assets and enemy 
positions can be displayed. Such a display gives the commander an accurate picture of 
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the situation to which he can immediately understand and react. Solutions might even 
seem more obvious when he can actually look the situation over. A three-dimensional 
display of this nature can give the conunander more understandable information in a 
shorter time then status boards, two-dimensional displays and contour maps ever will. 

This three-dimensional display has more uses than just tactical situations. 
Planning and training are two other areas where this display is useful. To plan an air 
strike against a land target, we can first enter all intelligence information on radars, 
weapons installations, airfields, and possible targets. We can then display weapons and 
radar envelop>es and look for the best possible route. After plans are made, the display 
can be used to brief the air crews who will be flying the mission. They can get an 
accurate picture of what they can expect to see as the mission proceeds. The simulated 
display can be supplemented with digitized intelligence photos, if available. The display 
can then be used to monitor the actual mission in progress. 

Three-dimensional displays with real time animation have a place in the 
command and control environment. Such a display gives tlie user a more intuitive grasp 
of the conditions, making it easier and faster for him to interpret the situation. Current 
low cost graphics workstations are capable of producing a quality three-dimensional 
display that can greatly aid command and control. 

B . SCOPE OF THIS STUDY 

The scope of this effort is clearly quite broad. It builds upon previous work 
bringing us a step closer to the ideal command and control workstation. The focus is in 
two areas. The first area is to provide a user interface that is consistent with the overall 
goals for the system. We use an interactive system of multiple display windows 
controlled with a mouse. The second area is to start development of a realistic, real-time. 
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tliree-dimensional display using Defense Mapping Agency Digital Terrain Elevation 
Data. The goal of this system is to provide the data structures and algorithms required to 
realistically display the sea/land environment with real time motion simulation. 
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n. FOCUS 



A. PRELIMINARY RESEARCH 

Two computer graphics research projects at the Naval Postgraduate School have 
lead directly to the research on the current command and control workstation [Refs. 2, 3]. 
Adams developed a two-dimensional command and control display using standard NTDS 
symbology with color coding added. This system received track information over a local 
ethemet from another workstation. Adams’ work looked at the networking capabilities 
of graphics workstations as applied to a command and control system and showed that 
the workstation can be effectively used as a color NTDS display handling the standard 
operations [Ref. 2]. What remained was to improve the user interface and test the 
practicality of using windows to provide multiple, separately controlled displays on one 
workstation. 

The second project "FOG-M" started the groundwork for a three-dimensional 
display, by using graphics workstations to develop a flight simulator using actual digital 
terrain elevation data [Ref. 3]. The FOG-M system, while producing excellent images, 
had several limitations which had to be overcome before it could be used in a command 
and control display. An important factor in the design of a simulator is for it to look 
realistic but it is often not important for it to be accurate. Graphics "tricks" can be 
employed to produce a realistic looking image with a minimum of work for the 
computer. In the FOG-M system, the terrain is only drawn out to a distance of two 
kilometers from the viewing position, although it gives the app>earance of being much 
farther . For use in a real time command and control system, the terrain must be depicted 
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accurately and enough of it must be drawn to show the area of actual visibility. At a 
height of eye of only two meters, visibility to the horizon is three miles [Ref. 4]. 

B. WINDOWS 

There are many windowing systems available on graphics workstations. They are all 
the same in principle and provide about the same operations but differ in the actual user 
interface. No industry standard has yet emerged but any system’s operation can be 
simulated by writing an abstract system over the top of the resident system. This 
conforms to good software engineering practices by making the code more portable since 
changes to the resident system only effect the procedures that make up the abstract 
window system. Griggs developed a window manager abstraction that modeled the 
window systems popular on some personal computers [Ref. 5]. This windowing system 
can be modified to meet the needs of the command and control workstation by providing 
multiple window capability to the work done in [Ref. 2]. By adding an extra layer of 
software, some of the performance of the host workstation is lost. The degradation of the 
system is not significant in the two-dimensional system but for the three-dimensional 
display the performance of the host computer needs to be pushed to its limit to provide 
the best possible animation of complex scenes involving thousands of filled polygons. 
For this purpose, the native window manager on the IRIS 4D graphics workstation is 
utilized to provide the user interface. 

C. THREE-DIMENSIONAL DISPLAY 

It is important that a tactical three-dimensional display render the scene accurately 
and respond quickly. It is relatively easy to draw a complete and accurate picture when 
time is no object but a tactical display must be real-time to convey the required 
information. In a tactical environment, the situation can change in a short period of time. 
If the information is several minutes old before it is displayed, it loses much of its 
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usefulness. Enough information must be displayed to depict all aspects of the situation so 
speed cannot be achieved by leaving out information. The display must update often 
enough to give the user a sense of movement. This animation provides some of the 
intuitive information that makes this type of display especially useful. 

Three-dimensional scenes are normally rendered using filled polygons to 
approximate curved surfaces. This cuts down on the computation time required to show a 
scene but accuracy is lost with the resolution of the polygons. In general, the more 
polygons you draw the better the scene looks. It also takes a proportionally longer time to 
draw the scene. The power of a graphics workstation is generally quantized by the 
number of z-buffered, Gouraud shaded polygons that can be drawn in one second. Since 
each manufacturer measures this value differently, comparisons are not definitive, 
although it is a good indication of the capabilities of an individual model. The power of 
graphics workstations is increasing at a fantastic rate with each new model that comes 
into production. The graphic workstations in the Naval Postgraduate School’s Graphics 
and Video Laboratory have kept up with these adveinces, staying on the leading edge of 
current technology. The IRIS 2400, released in 1985 can draw 650 z-buffered, Gouraud 
shaded polygons per second. The current models in use, the 3120 and 4D/70G have rates 
of 1,000 and 5,500 respectively. The next upgrade to the 4D is to be released in May 
1988 and is advertised to draw 60,000 z-buffered, Gouraud shaded polygons per second. 
For a further comparison of these machines, see Table 2.1 [Ref. 6]. With new 
experimental architectures and multi-processor systems, the future is even brighter. Each 
new advance makes the rendering of more complex scenes possible and the need for even 
more powerful machines more apparent. Even with the advances of the near future, 
machines wUl be pushed to their limit with real-time three-dimensional displays. Each 
new advance’s additional graphical and computational power is quickly utilized. The key 
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Table 2.1 COMPARISON OF SILICON GRAPHICS’ WORKSTATIONS 


Machine 


2^Buffcrcd, 
Oouraud shaded 
Polygons per 
second 


Z-Buffered, 
Gouraud shaded 
Polygons per 15th 
second 


CPU MIPS 


Flat-Shaded, Non- 
Z-Buffered Po- 

lygons per second 


Flat-Shaded, Non- 
Z-Buffered Po- 

lygons per 15th 
second 


IRIS-3120 


1,000 


67 


2 


5,000 


333 


nus-4D/7oa 


5,500 


367 


10 


25,000 


1,667 


IR1S-4D/70GT 


60,000 


4,000 


13 


32,500 


2,167 


♦IR1S-4D/MP? 


200,000 


13,333 


120 


300,000 


20,000 


* under development 


t 











to producing a good, three-dimensional display still depends upon the programmer 
writing efficient code to draw the best possible picture with the fewest possible polygons. 

The FOG-M and VEH visual simulators, developed at NFS, used Defense Mapping 
Agency digital terrain elevation data from Fort Hunter Liggett California for their 
displays [Refs. 3,7]. There are graphic techniques or "tricks" that can be used to make a 
scene look realistic with fewer polygons. Some of these tricks were used in FOG-M and 
VEH to draw exceptional scenes with a minimum number of polygons. Some of these 
techniques sacrifice accuracy for performance. Unlike a simulation, a tactical tliree- 
dimensional display must be both realistic and accurate. New metliods must be found to 
reduce the number of drawn polygons without giving up the accuracy. Images in FOG-M 
and VEH were only drawn to a maximum distance of two kilometers reducing the 
number of polygons that must be drawn. The appearance of greater distance was 
achieved by using perspective settings like different lenses on a camera. Setting a wide 
field of view in the perspective call gives the same effect eis a wide-angle lens. Objects 
that are in the background appear much farther away. Since the vertical resolution is not 
affected by this technique, an additional scaling of the actual elevations gives a realistic, 
although not always accurate, display of terrain. Since a tactical display must also be 
accurate, all the terrain that can be seen must be drawn in the correct {perspective and the 
elevations must be accurately represented. It requires a tremendous number of polygons 
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to represent the visible terrain if all the terrain is drawn at the same resolution. Since 
things in the distance cannot be seen as clearly as close by things, they do not need to be 
drawn at the same resolution as those that are closer. The number of polygons drawn to 
represent the terrain can be reduced if more polygons are used to represent the terrain 
closest to the viewpoint while the terrain in the distance is drawn at a lower resolution 
using fewer polygons. 

D. SUMMATION 

This study brings the command and control workstation of the future a couple of 
steps closer. Both user interfaces with windows and techniques for drawing terrain in a 
three-dimensional display have been studied and implemented. The focuses are to 
provide a user-friendly program framework for future work on the command and control 
workstation and to make an accurate and realistic real-time three-dimensional display of 
digital terrain elevation data. 
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m. WINDOWS AS A USER INTERFACE 



The command and control workstation of the future (CCWF) is a tool designed to 
present tactical information in a way that the user can easily interpret. Like any tool, its 
only as good as its user interface. The CCWF must be designed with the user in mind. A 
device that is complicated, or hard to use is likely to go unused even if it is functionally 
perfect. Windows have been used to improve the interface of personal computers and 
commercial workstations. Their use can also enhance the user interface of the command 
and control systems used by the Department of Defense. 

A. WINDOW DISPLAYS 

Windows are the basis of the user interface for the CCWF. They provide flexibility 
and the effect of many displays for the price of one. The technique of multiple windows 
as a user interface is stiU maturing in the computer industry. There are many diverse 
window management systems on the market but no industry standard has yet emerged. 
The services provided by all the systems are similar and a viable user interface can be 
developed under any of these systems. 

1. Multiple Windows 

Tlie CCWF uses multiple windows on a single screen. Each window is used to 
provide a particular type of information in a format that is easy for the user to 
understand. There are windows for two-dimensional radar display, chart display, three- 
dimensional display, and auxiliary information. All these windows cannot be shown on a 
screen at one time. The user can select which windows to show, where on the screen it is 
displayed and how big it is. The windows can interactively be opened, closed, moved, or 
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resized. They can be pushed or popped in order to be drawn under or over the other 
windows. These operations allow the user to change the display according to the 
particular needs of the current situation. The window system must know where the 
window is to be drawn, what size to make it, what to draw in the window, and how it 
should be drawn, relative to the other windows. 

2. Mice and Menus 

The standard computer interface is the typewriter-type keyboard. Even with 
special function keys, the user has to remember special codes and it takes multiple 
keystrokes to accomplish simple operations. With a mouse or track ball controlled cursor, 
an operation can be executed simply by pointing the cursor at a selection displayed in a 
menu on the screen and liitting a button. The menu presents choices in easy to understand 
text. All the user has to remember is how to get the menu and how to press a button. 

The mouse controlled cursor can also select certain objects from a window. For 
example, the user can bring up amplifying information about a contact by pointing at the 
contact on the NTDS screen and pushing a button. This technique is currently used on 
standard NTDS displays. The CCWF expands on this idea by having different cursor 
modes. The user changes the cursor by pointing at a menu in the display. Each cursor has 
a separate function relative to the window it is in. 

3. Mice in Multiple Windows 

Using a mouse with multiple, overlapping windows is a much more complex 
problem then with a single window or tiled window stmcture. The system must 
determine what window the mouse event occurs in. It would be nice for this operation to 
be transparent to the user. The user points and the system knows which is the referred to 
window. On a multi process system, the window system must also be able to determine 
with which process the user is interacting. 



.f?- 
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B. WINDOWS ON THE IRIS 



The IRIS graphics workstations from Silicon Graphics Inc. were selected as die 
primary graphics device for the NFS Graphics and Video Laboratory. These are 
inexpensive, high power, high resolution, color computing systems for two-dimensional 
and three-dimensional computer graphics. The IRIS provides a powerful set of graphics 
primitives and custom VLSI circuits combined with conventional hardware and 
software [Ref. 8]. The heart of the system is a special VLSI chip called the Geometry 
Engine. A set of these chips make up a geometry pipeline that accepts points, vectors, 
polygons, characters, and curves in user defined coordinates and transforms them to the 
screen coordinate system. The pipieline does all rotations, transformations, clipping, and 
scaling to draw the objects the correct size at the correct location. The IRIS has the 
capability to use multiple user interface devices. Besides the standard keyboard, the unit 
has a mouse with three control buttons. Optional equipment includes button and dial 
boxes. A window management system is included as standard software on the IRIS. 

1. Multiple Exposure Window Management System 

The Multiple Exposure Window Management System (MEX) is a user 
interface environment that controls multiple windows [Ref. 9]. This system is a standard 
part of the operating system on the IRIS 4D and an optional program that can be run on 
the earlier models. It provides multiple windows, mouse controls and a pop-up menu 
system. Multiple windows can be controlled by one process and several processes can 
have windows open on the display at one time. This is a very powerful system that can be 
used to design an exceptional user interface. 

a. The Event Queue 

The user communicates with the computer system through input devices. 
He pushes a function key, types a message on the keyboard, uses a mouse, etc. There are 
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two ways for tlie input device to communicate with a process. The first is for the process 
to read the value of every device. This is done every time through the main program 
loop, even though the value of the device has not changed. This is known as polling the 
devices. Another method is to send the controlling process a message whenever a change 
in a device has occurred. The message is placed on a queue and the controlling process 
checks to see if any messages have arrived. Polling a device is less efficient when values 
are not frequently changing. Wliy read the device and act on the input when no change 
has occurred? With an event queue, the system places a message on a queue each time a 
change in state occurs on selected devices. The process can check for any and all input 
by simply using a while loop to read and act upon all the messages in the queue. 

while ( queue not empty ) do 

{ 

process message 

} 

This way the process only takes tune to act on changes and not on checking all the 
devices every cycle tlirough the loop. 

This study is concerned with communication to a single process but is 
implemented on a multi-process system. Tlie window manager on IRIS is designed to 
work in a multi-process environment where several processes running concurrently might 
have displays open on the screen. One process must be designated to receive input. This 
is called input-focus on the IRIS system and can be changed interactively using the 
mouse and MEX menus. All events are placed on the queue of the process with input- 
focus assigned. 

b. Pop-Up Menus 

Menus are provided by the IRIS window manager to make the interface 
between the user and the system as easy as possible. These menus are controlled by the 
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mouse and appear at the cursor location when the right mouse button is pressed [Ref. 9]. 
Keeping the right mouse button pressed and moving the mouse highlights the different 
menu selections. When the correct menu selection is highlighted, the mouse button is 
released. The selection is then executed and the menu disappears. 

The MEX system uses a predefined pop-up menu to control window 
operations. Figure 3.1 shows the operations that can be executed from this menu. This 
menu is activated by placing the cursor in the title box of the window that requires the 
action and holding down the right mouse button. 

There are also user defined menus. These menus are defined in the 
application program. When this menu is executed, a message is placed on the 
applications event queue. Input from the mouse and menu goes to the process with input 
focus. 




commandr* 




help 




new window ► 


NTDS window 


NTDS cont 


chart window 




3D window 



Figure 3.1 MEX System Menu 



MEX User Defined Menu 



c. Window Management 

The IRIS window manager has an excellent set of routines to manage 
windows from within a user application. The application program can open and close 
windows, changing the display based on the program or user input. For example, if the 
application receives a message from another unit, it can open a window and display a 
message telling the user what has happened. The user can then close the window with 
some predefined command, mouse button, return key, etc. 

Whenever a window is opened, the system returns an identifier to that 
window. The graphics window identifier (GID) is a long integer that is used to identify 
what window is being referred to in a program. This value is used to close a window or 
set the window to receive graphic input. Only one window at a time can be set to receive 
graphics input. Most of the MEX procedures act on the window that is set to receive 
graphics input. 

The system allows the programmer to set certain constraints on a window. 
Maximum and minimum size can be specified, the X to Y aspect ratio can be set, or the 
window position and size can be fixed. All these commands can be changed by tlie 
program after the window has been opened. If constraints are set, the user cannot violate 
these constraints from the MEX interactive menu. 

All the operations in the MEX command menu can be executed from 
witliin the program, allowing the programmer to devise a window control system that 
meets the needs of a particular application. 

C. IMPLEMENTATION 

MEX was designed to mn on a multi-processing system and works best with many 
processes, each with one graphics window. This study is primarily looking at a system 



18 



where one program, the command and control workstation, is controlling multiple 
windows. The buUt in functions of MEX need to be expanded to keep track of the 
different windows. 

Enhancing the program manager to meet the needs of the command and control 
workstation can be done in two ways. An abstract window manager can be constructed 
using the software engineering principle of information hiding. This abstract window 
manager would consist of procedures that would call the appropriate MEX functions and 
keep needed information in its own data structures. The programmer calls procedures in 
the abstract manager and does not deal with MEX directly. A basic abstract manager was 
developed by Larry Griggs in [Ref. 5]. The other method would be to develop a data 
structure that would maintain the infonnation needed to control the windows using MEX 
calls directly. This method does not make the software easily portable, but it is more 
efficient. By removing a layer of procedure calls between the user application and the 
system window manager, perfonnance is improved and the complexity of the program, 
as a whole, is improved. 

The MEX pop-up menu system is not always the best way to present choices to the 
user. If there are many possible choices, pop-up menus can become confusing and hard 
to manage. To keep the interface simple, multiple menus are used with each menu 
designed to present its choices in a way that makes it easy for the user to make his 
selections. 

1. Menus in a Simple Interface 

Operation of the command and control workstation allows the user to make 
many choices about the configuration and operation of the workstation. Placing all the 
choices in one MEX menu with roll-over submenus presents the user with a menu that is 
too complex to be easily used. Another problem is with the MEX system. There is no 
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way to select several things from a menu at once. There are two parts in the solution to 
these problems. The first is to modify the menu depending on the possible choices the 
user can make from his current state and which window the cursor is over at the time of 
the call. This allows the user to see only tlie choices that make sense for his current state 
and window. The second part of this solution is to take infrequent choices, such as 
configuration and set-up options and options that don’t work well in the pop-up menu 
system, and place them in other menu systems that present the choices in a better way. 



a. Multiple Menus 

Presenting different menus for different situations and windows requires 
that the program be able to tell which window the cursor is over when the user calls a 
menu. This is not a built in function of MEX but is fairly easy to do. The windows are 
drawn in a stack. When a new window is opened, it is placed on the top of the stack. 
When a push is ordered for a particular window, it is moved to the bottom of the stack 
where it is drawn under all the other windows. A pop operation moves the window to the 
top of the stack. The main program needs to keep track of where each window is on the 
stack. When a menu is ceiUed, the program starts at the top of the stack and checks each 
window to see if the coordinates of tlie cursor position falls inside the window boundary. 
The first window that succeeds is the window the user is referring to in his request. The 
following code shows a C function that returns the GID of the window where the cursor 
is or a - 1 for error. 

■/* array of graphic window identifiers */ 

/* windows [0] is the top window ♦/ 

GID windows [ 10] ; 

/* function which_window returns the GID of the top 
widow where the input X/Y parameters lie inside 
the window boundary */ 

GID whi ch_window(mousex .mousey) 
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found = FALSE; /* initialize */ 
i = 0: 

while((not found)or(i <= number of windows)) 

{ 

/♦ make window to be checked current graphics window 
so following procedures will refer to correct window */ 
winse t (windows [ i ] ) ; 

/♦ get window coordinates */ 
getsize(sizex.sizey) ; 
getorigin(originx,originy); 

if (mousex > originx) and (mousex < originx + sizex) and 
(mousey > originy) and (mousey < originy + sizey) then 
found = TRUE; 
else 

i = i + 1 ; 

1 / * wh i 1 e * / 

if (i > number of windows) 

return(-l); /* not in any of the windows */ 
else 

re turn(windows [ i ] ) ; /* the GID of the first window found 

*/ 

I 



b. A Virtual Control Panel 

A typical NTDS display has the capability to filter out contact types. Tliis 
simplifies the display by only showing the contacts that the user wants to see. This 
feature is controlled by a panel of hardware switches on the console. The command and 
control workstation of the future can show multiple NTDS displays on one screen. The 
controls for multiple displays are too varied and complex for a hardware control panel. 
Interactive menus must be used to control the different features of the workstation. A 
virtual control panel is used to set up an NTDS display window. Tlie user positions the 
cursor over the NTDS window he wishes to change. The pop-up menu for this window 
has NTDS control as one of the selections. When this selection is executed, a new 
window is opened as a virtual control panel (see Figure 3.2 ). The cursor is bound to the 
inside of this window and no other action can be executed until the user is through setting 
the controls. The virtual control panel is a table of boxes, each box is labeled accordmg 
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Figure 3.2 The NTDS Virtual Control Panel 



to its function and color coded to indicate its setting. Red is off and blue is on. The 
"switch" is toggled by pointing the cursor at the appropriate box and clicking the left 
mouse button. The color changes indicating a new setting for that switch. Changes to the 
panel can be made until the exit box is pressed. The window is then closed and any 
changes are entered into the user record of the window where the execution of the pop-up 
menu occurred. This allows each of the NTDS displays to be controlled separately and 
display a variety of information. One window can show the air picture, one the surface 
and another can be set to display only hostile units. 



22 



2. An Abstract Window Manager 



The purpose of this preliminary version of the command and control 
workstation is to demonstrate the functionality of using multiple windows and menus in 
developing the user interface. The starting point of this program is the commander’s 
display system develop>ed by Rodney Adams [Ref. 2]. The commander’s display system 
uses color graphics to display a single NTDS radar display. Windows are not used in this 
program. A simple abstraction of a window management system was developed by 
Larry Griggs for his network monitor [Ref. 5]. Griggs’ window manager simulates tlie 
user interface used in some popular personal computers. The windows are controlled by 
clicking the mouse in certain predefined regions in each window. For example, holding 
the mouse button down in the lower right comer of the window then moving the mouse 
to a new position, changes the size and shape of the window. This is in contrast to the 
MEX system, where windows are controlled with a special pop-up menu. Many of the 
procedures used in this abstraction are direct calls to MEX procedures. 

The current version of the CCWF uses parts of the NTDS display from Adams, 
and an expanded and modified version of the Griggs window manager. This program 
runs on the IRIS 3120 under the MEX window management system. Tliis preliminary 
program demonstrates the operations required by the user interface for the command and 
control workstation. 

a. Multiple Windows 

The abstract window manager solves some of the problems in the MEX 
system. It keeps track of each window, its size, position, and content. It has procedures 
that evaluate in which window a mouse event occurred. Additions have been made to 
allow constraints to be placed on each individual window. Predefined constraints can be 
set by the programmer for maximum size, minimum size, and X/Y aspect ratio. The 
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aspect ratio is used for the NTDS display to keep the scale the same in the x and y 
direction. This keeps the perspective constant so the display looks ’’right" when the size 
of the window is changed. The shape of the window remains constant. The infonnation 
to be displayed in the window is scaled to match the window size. Multiple open 
windows can be shown tiled, Figure 3.3, or overlapped. Figure 3.4, and moved around to 
give the user a picture that is easiest for him to interpret. 



(1) Data Structures . Window information needs to be saved when 
multiple windows are used in one program. The abstract window manager hides this 
infomiation in a package of procedures tliat can be called by the programmer to control 
the multiple windows. The following is the data structure used in this abstraction. 



/* structure used to record infonnation on each window */ 
typedef struct WindowType 
( 

/* the user provides these fields when he opens a window ♦/ 

char title[50]; /* title to be displayed in title bar */ 

Object *obj ; /* ptr to the object to be drawn in window */ 

short Backgr oundFl ag ; / * boolean: does window always stay in 

backgnd? if so, it can’t be moved, 
popped or resized and should be as 
large as the screen to avoid losing 
a normal window beneath it */ 

long re fConl , re fCon2 ; /* user uses these for any purpose he 

likes. Refcon one is used as pointer 
to user s t rue ture */ 

/* MTWM keeps these fields current */ 



IRIS-mex-prov ided unique window id */ 
x,y dimensions of the window */ 
screen coords of lower left corner of window*/ 
are constraints set */ 
constraint values */ 

long minx,miny; 
float aspr a t i o ; 

} Window; 



1 n t 


wid; 


!* 


long 


wx,wy ; 


!* 


long 


orgx,orgy ; 


1 * 


shor t 


max ,mi n , aspect ; 


1 * 


long 


maxx ,maxy ; 


/* 
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Figure 3.3 Tiled Windows 
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This record contains information that can only be accessed by the procedures in the 
window management package. When the process needs to know what window a mouse 
event occurred in, a package procedure called whichwindow() returns the information. 

Anotlier requirement imposed by multiple windows is keeping track 
of what the user wants in each window. This information is application dependent and 
should not be part of the abstract window manager. Each window has a user record that 
has information about what the user wants drawn in each window. The following 
structure is the user record format used in the CCWF implementation. 

/* Data structure used to share user interaction 
information, one user record is assigned to each 
window. A record for an open window will be marked 
as used ♦/ 
typedef struct { 

Object user_object; /*the object for this window*/ 

int win_type; /*int: type of window*/ 

Window *wind; /^pointer to window record*/ 
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More Boolean Flags to filter contact types 
one entry for each possible contact designation 

)user_s t rue t ; 

These records are modified by the user through the use of various menus. There is a 
maximum effective number of windows that can be open at one time. The data structure 
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for the CCWF implementation is arbitrarily set at ten windows. The number of windows 
that can be effectively handled depends on the complexity of the window contents. More 
then four NTDS windows slows the system to an unacceptable level on the IRIS-3120. 

In order to know which user record to change, the window system 
must know what window the cursor is over and what user record is associated with that 
window. Pointers bind the window structure and the user structure together when a new 
window is opened. 

b. Tlie Windows 

The current system uses five types of windows. A window is used to 
display the NTDS control panel, another is used to display an intelligence photograph of 
a selected contact type. These two windows are only open for a short time and must be 
closed before work continues. There is a background window that cannot be closed or 
sized. This window just provides a background for the display. It can be used to display 
help information or the three-dimensional view can be implemented in this window. The 
two remaining are window types which show information, a 2-D radar and a chart 
window. Other typ>es of infonnation windows can be easily added to the system. 
Multiple numbers of each of these windows can be used. The functionality of this system 
can be demonstrated with only one type of infomiation window, the NTDS window. A 
chart window selection is presented in the menu but its selection opens an empty 
window. 

(1) Sel ecting Items From A Window . The IRIS graphics library 
routines allow the user to select objects from the screen. This is controlled with the 
cursor and the left mouse button. When the left mouse button is pressed the system is put 
in "pick" mode. Pick mode allows the program to determine what designated objects are 
within a defined region around the cursor’s location. This process is used by the abstract 
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window manager to determine if the user is trying to move or reshape the window. It is 
also used to pick certain objects from the contents of the window. 

(2) NTDS Windows . The NTDS window shows features tliat can be 
used in any of the windows. Besides the virtual control panel, there are three different 
cursor modes, and 6 control boxes that act as a permanent menu. The different cursor 
modes are selected by picking the cursor from the permanent menu on the right side of 
the window (see Figure 3.5 ). Any of the cursors can be used to manipulate the windows 




Figure 3.5 NTDS Window 



29 




or select items from the permanent menu. The top cursor, an arrow, is the default cursor. 
When the arrow cursor is active and a contact symbol is picked from the window, an 
information box shows the contact’s course, speed, etc. The middle cursor, the one that 
looks like a picture frame, displays a picture of the contact. This is just an example. This 
cursor could be used to show any amplifying information. For example, it could display 
a menu and allow the user to select what type of amplifying infonnation he wants to see. 
The menu choices would vary depending on the information available about that 
particular contact type. The third cursor looks like a sight and changes the window 
origin. The center of the grid becomes the contact selected by the user. All movement is 




Figure 3.6 Information Box 
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displayed relative to this contact’s course and speed. The remainder of the permanent 
menu allows the display to be shifted in the window to show the part of the area that is of 
interest. Figure 3.7 shows an NTDS window that has been shifted up and to the right. 

There are also zoom-in and zoom-out controls that focus on the 
center of the display. The techniques used in the NTDS windows can be used in other 
windows to give the user quick and easy control over the display. 







NTDS DISPLAY 
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Figure 3.7 Shifted Grid Display 
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3. An Alternative to the Abstract Window Manager 



Window controls are application dependent and can not be easily generalized 
into an abstract manager. The application £ind the host computer define what information 
needs to be saved about the windows. The two data structxires used in the abstract 
mcinager are bound together by pointers. The complexity of the program is improved if 
the structures are combined cind £in application specific window manager is used. A 
structure used in the prototype of the three-dimensional display places information 
required by all windows in one record type. 



typedef struct 

fields when he opens a window */ 

title to be displayed in title bar */ 
int representing window type, NTDS, Chart, 

3D, etc. Will determine what type of 
information is to be drawn in the window.*/ 
boolean: does window always stay 
in backgnd? if so, it can’t be moved, 
popped or resized and should be as 
large as the screen to avoid losing a 
normal window beneath it */ 

IRIS-mex-prov ided unique window id */ 
pointer to window specific record, 
record will contain information 
that is specific to the window type */ 

/* these values can also be obtained fromMEX calls */ 

long wx,wy; /* x,y dimensions of the window */ 

long orgx,orgy; /* screen coords of lower left corner of window*/ 

/* individual constraints for each window */ 

short max,min, aspect ; /* are constraints set */ 

long maxx,maxy; /* constraint values */ 

long minx,miny; 
float aspratio; 

I Window; 



/* the user provides these 



char title[50]; /* 

int Win type; /* 

short BackgroundFl ag ; /* 

int Gid; /* 

long pointer; /* 



Information that is window specific is placed in another structure that is pointed to by a 
field in the main window record. The following record is the window type specific 
stmcture used for the three-dimensional display. 
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typedef struct 



i nt 1 a t ; 
int longg; 
float posx; 
float posz; 
float posy; 
float crs ; 
float spd; 
float lookdir; 
float lookang; 
float max_vis ; 
int a 1 1 ached ; 
shor t gr idl ines ; 
) viewpoint ; 



/♦ lower left whole latitude of pos */ 

/♦ lower left whole longitude of pos 
/♦ position relative to lat longg in yards^/ 
/* position relative to lat longg in yards^/ 
/♦ altitude in yards above sea level ’*'/ 

/♦ motion of viewpoint ♦/ 

I* motion of viewpoint */ 

/♦ Chg view direction without course chg ♦/ 
/* angle down from vis horizon */ 

/♦ set maximum range, current 60 Nvi */ 

/♦ contact number attached to 0 if free */ 

/♦ show grid lines ? */ 



The MEX system controls windows with a pop-up menu that is called from the 
window title bar. The window manager abstraction used in this study controls the 
windows with the cursor in certain defined, but unlabeled, regions of the window. Both 
techniques work and provide an easy to use interface. If an application specific window 
manager needs to be implemented on top of the native window manager, performance 
and complexity are improved if the applications window manager is as close as possible 
to the native window manager. All the MEX system functions except push and pop can 
be used directly from the MEX menu. There is no way to keep the window stack straight 
if the system executes pushes and pops directly. The MEX system menu cannot be 
changed by the application programmer to remove the unwanted functions. An 
application menu system can be developed that calls the MEX routines from the 
application program and stores the needed window infonnation. Menu controlled 
windows are easy to use and provides more flexibility then tlie method used in the Griggs 
abstract manager. 



D. CONCLUSIONS 

Multiple windows with mouse controlled menus form a very powerful and flexible 
user interface for the CCWF implementation. There is no real industry standard for 
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window management systems. Each manufacturer has designed their window interface to 
work efficiently with sj)ecific hardware and applications in mind. Until a standard 
interface emerges, different techniques should be considered. Design decisions should 
not be based on the system used by some subset of the window oriented computers. By 
programming a window manager that is application specific and that uses the native 
window manager, a user interface that meets the needs of the program can be developed 
on any of the window systems. A production model of the CCWF will be a special 
purpose computer. An efficient window manager for a special purpose computer must be 
designed to take advantage of the hardware and provide all the functions required by the 
specific application. The MEX system is an excellent window manager and will work 
very well in this application. The new release of the IRIS window manager in the IRIS 
4D/GT places a token on the event queue whenever a window is pushed or poped. A 
function is also provided that will indicate where a particular window is in the stack. The 
CCWF, implimented on the IRIS 4D/GT, can use the native window manager directly. 
The only information the application program needs to save is the GID of each window 
and the information about what should be drawn in each window. 
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IV. DIGITAL TERRAIN DATA 



To model the terrain over a particular area of the earth’s surface, a database 
representing the actual terrain is required. This database should consist of a set of points 
covering the area to be modeled and show the actual elevation of the terrain at these 
points. In addition it would be nice to know more about the terrain at each of these 
points so that future applications can add man-made structures, vegetation or color to 
make the images more accurate and informative. The data used in this study is from the 
Defense Mapping Agency’s Digital Terrain Elevation Data (DTED). 

A. DEFENSE MAPPING AGENCY 

The Defense Mapping Agency (DMA) was established in 1972, combining tlie 
mapping, charting, and geodosy functions of the defense community into one 
organization. Its mission is to provide Department of Defense users with "complete, 
credible and effective mapping, charting, and geodetic products, services, and 
training" [Ref. 10]. The DMA Combat Support Center in Brookmont, Maryland is 
primarily responsible for the distribution of DMA products to the military services. The 
product of primary interest for use in a three-dimensional display is the Digital Landmass 
System (DLMS) Database maintained by the DMA Aerospace Center, St. Louis, 
Missouri. 

1. Digital Landmass System Database 

The DLMS database is in two parts, cultural features and terrain. The terrain 
files have elevation data in meters above mean sea level. The cultural files have 
information about the terrain. These two files are compatible. The horizontal position of 
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the cultural data matches the terrain data insuring that features in the cultural files 
coincide with the proper terrain elevation locations. 

a. Resolution of Data 

The DLMS database is available in two resolutions, level 1 is intended for 
broad worldwide coverage and level 2 is intended to cover small areas of interest. The 
interval between data points for level 1 resolution is three seconds of latitude arc or 
approximately 100 yards. Level 2 data is presented in finer detail with a data interval of 
one second of latitude arc. The corresponding interval of longitude changes with 
increasing latitude. See Table 4.1 for exact intervals [Ref. 11]. 

b. Cultural Data 

Cultural data is a generalized description and portrayal of planimetric 
features. In other words, what the terrain looks like. This file is a complex data structure 
that uses digital codes to describe a feature or area. Special codes are used to represent 
the predominant surface material of a feature or area. A few of the categories used are 
stoneA>rick, water, rock, soU, marsh, asphalt, and trees. In addition to the general surface 
makeup, unique significant features are also stored. These features are divided into three 
categories: areal features, liniear features and point features. Point features are unique 
features less then 150m by 150m in size for level 1 resolution and 30m by 30m in level 2 



Table 2. Terrain Data Interval 



Zone 


Latitude 


Level 1 
lat. long. 


Level 2 
lat. long. 


I 


0°-50° N-S 


3x3 seconds 


1 X 1 second 


n 


50‘’-70‘’ N-S 


3x6 seconds 


1x2 second 


n 


N-S 


3x9 seconds 


1x3 second 


IV 


N-S 


3x12 seconds 


1x4 second 


V 


80" -90^’ N-S 


3x18 seconds 


1x6 second 


NOTE: All values in seconds are in 


terms of arc measure. 
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resolution. Objects such as isolated structures, radar reflectors, tall buildings, aids to 
navigation, etc. fall in this category. Linear features are less then 150m in width for level 
1 resolution and less then 30m for level 2. This category includes features such as 
canals, streams, rivers, roads, railroad tracks, walls, fences, etc. Areal features are too 
large to be considered in either of the other two categories. Included in this category are 
parking lots, squares, mud flats, storage areas, etc. The cultural data file is very complex, 
containing much information not touched on here. The data obtained from this file can 
render a very acctuate picture of the chosen area, 
c. Terrain Elevation Data 

Elevation data is stored in separate files from the cutural features file. 
Both level 1 and level 2 data are stored as 16 bit integers representing the elevation in 
meters above mean sea level at each data interval. Level 1 terrain elevation data is the 
information used in this study to develop a three-dimensional display. The content and 
sj>ecifications for level 1 terrain elevation data are covered later in this chapter. 

B . DIGITAL TERRAIN ELEVATION DATA 

A command and control workstation for use in a tactical, sea/land environment must 
have a wide area of coverage. The area of interest for a commander can easily be a circle 
a 500 miles in radius from his position. Tlie three-dimensional display for this 
workstation must be equally far reaching. The digital terrain elevation data used in the 
FOG-M and VEH visual simulations is not sufficient for this application for two reasons. 
The data does not cover a large enough area. The Fort Hunter Liggett database is an area 
35 km X 36 km. This is not sufficient to show the feasability of managing and displaying 
the quantity of terrain data required for a tactical display. The second reason is that the 
Fort Hunter Liggett area is uninteresting for a sea/land environment. There is only a 
small stretch of straight coastline, containing no bays, inlets or islands. The southern 
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islands of Japan are an area with both interesting terrain and interesting coastlines and 
islands. It is that DMA data set on which this study relies. 



1. The NPS Japan Database 

A 10,800 square mile database of level 1 digital terrain elevation data was 
obtained from the Defense Mapping Agency. The area of interest is the southern part of 
Japan. This area has many islands and interesting coastal features wliich make it ideal for 
testing a three-dimensional display of a land/sea environment. See Figure 4.1 for a map 
of the covered area. 

2. Format 

World coverage of DMA level 1 terrain elevation data is divided into blocks, or 
cells, of one degree latitude by one degree longitude [Ref. 11]. The Japan database used 
in this study consists of 30 of these cells, distributed on four half inch magnetic tapes. 
Appendix A contains a list of the latitudes and longitudes of the individual cells on each 
tape. A map showing the position and coverage of these cells is in Figure 4.1. Each tape 
contains multiple cells of information. The cells are identified by the latitude and 
longitude of the southwest comer of the cell (cell origin). The data for each ceU consists 
of three files, a header file, a data file, and a trailer file. The format of the header and 
trailer files is very simple and uninteresting. Complete format information for the DMA 
Digital Terrain Elevation Data is presented in Appendix B. The data file consists of three 
record types: 

* 1 Data Set Identification Record (DSI) 

This record contains 648 bytes of information about the data classification, 
resolution, position and orientation. 

* 1 Accuracy Description Record (ACC) 

This record contains 2700 bytes of information about the horizontal and 
vertical accuracy of the data. The cell can be divided into one to nine 
subregions. Accuracy data is presented for the overall cell as well as each 
subregion individually. 
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Figure 4.1 Maps of Japan Database 
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* Data Record 

There is one record for each line of data points of equal longitude. These 
records contain the actual elevation data for the cell. A full cell of level 
one terrain data has 1201 data records. One for every three seconds of 
longitude. 

The area covered by each cell provides an overlap of points having positions of 
whole degrees of latitude or longitude. For example the elevation data for the point 3 IN 
131E is included in four cells. It is the southwest comer of cell 31N 131E, the southwest 
comer of 3 IN 130E, the northeast comer of 30N 13 IE and the northwest comer of 30N 
130E. The content and format of these records is covered below. 

3. Reading the DMA Standard Tape 

Digital data from the Defense Mapping Agency is delivered on large magnetic 
tapes. It takes 90 megabytes of disk storage to hold the files for the 30 cells of data 
obtained for this project. The only machines with enough permanent storage to keep this 
data are the ISI workstations used in the Multiple Backend Database project at NFS. 
Each of these machines has a 500 megabyte disk drive. A 125 meg partition on ISFVl 
was set aside to store and manipulate the Japan terrain database. 

The network of ISI computers has a tape drive capable of reading the DMA 
standard tapes. Readone.c^ is a simple program that reads one file at a time from the tape. 
The output filename is passed into the program as a command line argument. Each 
successive call to the program reads the next file on the tape. Tlie program is written in C 
and mns on the ISI workstations. 



' Appendix C 
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4. The Elevation Data 



Each cell of level I terrain data has sample intervals of three seconds of 
latitude arc by three seconds of longitude arc for longitudes between 0 and 50 degrees 
north and south. These points are divided into data records of equal longitude. To provide 
an overlap, cells points of whole degree latitude and longitude are shared by adjoining 
cells. A full data record consists of 1201 data values stored sequentially by ascending 
latitude. 1201 of these records make up the cell. They are stored sequentially by 
longitude starting with the point of origin (see Figure 4.2 ). 




Last data 
value 



northeast 
corner of 
cell 



First byte Is a sentlnai 
Value Is AA hex 



Data records are stored In order of ascending longitude 
Values In each record are for the same longitude 
Each record Is Incremented by 3 seconds of longitude 



Figure 4.2 Diagram of Cell Data Storage 
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The Data Record has eight bytes of header information before the data and a 
four byte checksum after the last data point. The header information consists of: 

* 1 byte recognition sentinel, AA hex 

* 3 byte Sequential count of the block within the file 

* 2 byte Longitude count, a sequential count of the number of data records 

from the origin (southwest comer of the cell). 

* 2 byte Latitude count, the starting latitude of the record in units of 

the data interval. Normally zero for a full cell of level 
one data. 

The data values are 16 bit signed magnitude binary integers representing the 
elevation in meters above mean sea level. The sign is the high order bit. Negative values 
are not complemented. This gives a value range of +32767 to -32767. The actual range of 
values is +9000 to -12000 meters. The checksum value is the algebraic sum of all the 
eight bit values in the record. 

The data is easier to use and store in the form of a two-dimensional array of 
data points without the extra information. Extract.c is a program that takes a data file 
from one cell and writes only the elevation data to an output file for later use. The data is 
written sequentially, starting with the first data record from the file. This allows it to be 
easily read into a C array. The filename for the output file is the latitude and longitude of 
the southwest comer of the data. For example, 31N131Eis the file name for the cell with 
southwest comer at 31 degrees north latitude 131 degrees east longitude. This 
information is extracted from the cell’s data set identification record. Tlie complete 
format infomiation from [Ref. 12] is provided in Appendix B. 



^Appendix C 
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V. A THREE-DIMENSIONAL TERRAIN DISPLAY 



A real-time, three-dimensional, animated display provides more information and is 
easier to interpret then a traditional two-dimensional presentation. It is also much more 
difficult to draw. A scene that shows enough information to be useful is complex. It 
requires many polygons to accurately depict even simple situations accurately. Tlie 
command and control workstation is interested in the sea/land environment. The first 
step to providing an accurate and useful three-dimensional display is to draw land and 
ocean scenes in a near real-time display. 

A. PROBLEMS 

Real-time animation is considered to be 30 frames per second. At this rate, the 
human eye cannot detect the change of frames and the animation appears smooth. It 
would be nice for a tliree-dimensional, tactical display to update that fast, but it is not 
necessary. An update rate of two or three frames per second looks jumpy, but it conveys 
a sense of motion to the viewer and shows the appropriate, up to date information. A 
very large area is seen from an altitude of 300 ft. Assuming a field of view of 45 degrees, 
visibility of 20 miles and DMA level one digitel terrain elevation data, this area has 
67,916 data points. It requires 135,832 fiUed triangles to represent the terrain and takes 
the IRIS 4D/G about 90 seconds to draw using z-buffering. This is improved upon by 
drawing the land with filled polygons and drawing the ocean as an underlying blue plane. 
It requires 54 seconds to draw one frame. Computer upgrades will improve these times 
but not enough to give an acceptable animation rate. A new method must be found to 
draw the terrain faster without a loss in accuracy. 
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Eadi cell^ of terrain elevations has 2.8 megabytes of data. Assuming a maximum 
visibility of 60 miles, four cells of data is the maximum that is required for any one 
scene, (see Figure 5.1 ). Four frames contain 11.2 megabytes of data. This data must be 
available to the program for each frame that is drawn. The digital terrain database being 
used in this project consists of many islands and a lot of water. The ocean is represented 
as zero elevation. Space complexity can be improved by compressing the data, i.e. not 
storing all the zero data. 

The third problem addressed in this chapter is actually a set of problems dealing 
with drawing the terrain. The terrain data is a set of discreet points 100 yards apart. The 
ocean is represented by points of zero elevation while land is any elevation 




60 NM 




Four Cells 
of Digital T errain 
Elevation Data 




60 NM 



Figure 5.1 View Area Covers a Maximum of Four Cells of Data 



'Represents one degree latitude by one degree longitude area (Chapter 4) 
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greater then zero. How is the shoreline drawn between these points? Other problems that 
are covered are concerned with drawing in z-buffer mode and how to transition between 
different drawing resolutions. 

B. DRAWING THE TERRAIN 

The terrain in a tactical three-dimensional display must be drawn in correct 
proportion to the actual view. Not only must the vertical and horizontal scale model the 
real terrain but the area displayed must match the area that can actually be seen. 

1. Scale 

The data interval for digital terrain data is in seconds of arc latitude and 
longitude. One minute of arc latitude varies between 6,046 ft and 6,108 ft. This 
corresponds nicely to the use of nautical miles (NM) as the basis for a scale. One NM is 
1852 meters or 6076.11 feet [Ref. 11]. A general rule of thumb used in navigation is one 
nautical mile equals 2,000 yards. The longitudinal scale is dependent on the latitude. At 
the equator, the distance between whole degrees of latitude and longitude are both equal 
to about 60 NM. As latitude increases, the interval for degrees of latitude stays about the 
same but the arcs of longitude converge. At 30 degrees N, the start of our data, the 
distance between adjacent arcs of longitude is 52 NM. The data point interval for the 

DMA data base'* is three seconds of latitude and tluee seconds of longitude. Tlris equates 
to approximately 100 yds between points north or south and 86 yards between points east 
or west. For simplicity, the initial implementation of the three-dimensional display uses 
the value of 100 yds as the interval between all data points. 



*The database of Southern Japan used in this study (Chapter 4) 
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Tlie first chapter of [Ref. 11] states that "Relief information to DMA standard 
digital format is on a three seconds of latitude (approximately 100) meters matrix". 
Using 1852 meters as a close approximation to one degree of latitude, the actual value is 
92 meters for three seconds of latitude. A much better approximation is 100 yards for 
three seconds of latitude. The actual value is 101.25 yards. 

The DMA digital terrain elevation data values are in meters above mean sea 
level. To keep the scale constant, this value is converted into yards. The relationship, one 
yard is equal to .9144 meters is used as the conversion factor. This correction is applied 
when the data is preprocessed into a form that is compatible with the data stmcture used 
to store the data. 

2. Visibility 

Visibility is determined by the curvature of the earth. At an eye height of 6 ft, 
visibility is three miles. This distance increases with the height of eye of the observer. 
The area that can be seen is approximated by drawing the area from the view point to the 
horizon. Since items with an altitude greater then zero can be seen past the visible 
horizon, a minimum visibility of 10 NM is used to insure that land and objects relatively 
close are seen. Objects further away that can be seen over the horizon are indistinct and 
generally are not of interest. A maximum visibility of 60 nm is assigned to simplify 
determining what data cells are needed. The following formula, derived from, [Ref. 4] 
is used to calculate the visibility (VIS) in yards given the height of eye (HE) in yards. 

Vis = 3962.8 x 

The visibility is used to calculate the area that can be seen in one scene or 
frame, the visibility triangle (see Figure 5.2 ). This triangular area is computed using tlie 
view point, the direction of view from the view point, the visibility, and the field of view. 
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^ I boundary points 

Computed distance of visibility 
to the Horizon 

Figure 5.2 Visibility Triangle 



3. The Ocean 

The ocean can be approximated as a flat plane and drawn as one filled polygon 
at zero elevation. An area with data values of zero elevation is not drawn as many 
separate polygons. Instead, a blue base is drawn at zero elevation and only polygons 
with elevations greater then zero are drawn overlaying the blue base. This method 
allows scenes with a large proportion of water to be drawn much more quickly. This 
technique speeds up the the drawing process but causes a problem with the z-buffering. 
This problem and and the techniques used to correct it are discussed later in the z- 
buffering section of the chapter. 

A sense of movement is detected over terrain by the changing relief of tlie 
ground. This can be enhanced by artificially checkerboarding the terrain with two colors. 
The ocean generally has no relief and can be drawn as a single blue polygon. A sense of 
motion cannot be derived from a checkerboard pattern since a fill pattern is generally 
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drawn in screen coordinates vice world coordinates. Such a fill pattern does not show the 
effects of the view point moving in the world coordinate system. To provide a sense of 
movement over the water, a set of grid-lines is drawn on the ocean approximating 
latitude and longitude lines on a chart. The grid-lines are drawn dependent on the altitude 
of the view point. The ocean and grid-lines are drawn in procedure drawjerrain^. 

4. Shoreline 

The data can be viewed as a two-dimensional matrix of elevation data. These 
data values are the elevation of discrete points and do not show what conditions are 
between the points. The terrain is drawn by assuming that the area between the points 
can be represented as small planar triangles^ with the data points as vertices (see Figure 
5.3 ). Since a blue base is drawn first at zero elevation, triangles that represent ocean are 
not drawn. The land is drawn in alternating colors of green to give a checkerboard effect. 
Knowing nothing about the transition between points, it is hard to decide where to draw 
ocean and where to draw land when the adjacent points indicate there is a transition 
somewhere between them. The resulting picture must show a smooth transition that 
represents the actual shoreline. The database is converted into polygons by taking four 
adjacent data points that form a square and drawing it as two adjoining triangles. When 
all four data points are either zero or greater then zero both triangles are drawn the same, 
as either both ocean or both land. The problem is when the four points are mixed. One 
solution that works nicely is to draw a transition or shore when there is only one of the 
four points that is greater then zero. If two, three or all four of the points are greater then 
both triangles are drawn as land. This leaves four different ways to draw one triangle 



’Appendix E 

^Triangles are used to insure that the resulting polygon is always convex. 
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O Data Point 




Four adjacent data points 
are used as the verticies of 
two planar triangles 



Figure 5.3 Area Between Data Points as Planar Triangles 



land and one water (see Figure 5.4 ). Figure 5.5 shows a picture of a typical shoreline 
drawn with tliis method. Procedure drawpoly.c in Appendix D correcdy draws the 
triangles for four adjacent points given as parameters. 

C. THREE LAYERS OF RESOLUTION 

Drawing terrain out to the horizon requires too many polygons when all the data 
points are used. The natural perspective of a three-dimensional scene causes objects in 
the distance to appear small and indistinct. A three dimensional display has this same 
property. A polygon drawn at a distance might map to only one pixel in screen 
coordinates. Because of this difference, objects in the background do not need to be 
drawn in the same resolution as those in the foreground. The terrain data is converted to 
three resolutions. The foreground is drawn in level tluee resolution, data points 100 yards 
apart. This is the same resolution as the original data. The second level of resolution is 
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Land Data Point 
elevation > 0 

O Ocean Data Point 
elevation = 0 




All four points water both triangles are water 

Three of the points are water one triangle land one water 

Any other combination both triangles are land 



Figure 5.4 Shoreline Polygons 
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Figure 5.5 Sample Shoreline 



for the middle-ground. Data points are 1200 yds apart. This resolution has one data point 
for ever>' 144 level one points. Level one data is for drawing distant terrain. There are 
100 level two points for one level one point and the data points are 12,000 yards, six NM, 
apart. This data can be preprocessed to fit one of two proposed data structures. By using 
different resolutions to draw out different distances, the number of polygons can be cut 
by. an order of magnitude without degrading the display. Figure 5.6 shows two pictures, 
the first is drawn completely with high resolution, the second with a three-tiered 
structure. 
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Figure 5.6 Contrast Single and Multi Resolution 
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1. Implementation 



Large ajiiounts of data are required to accurately display terrain in a three- 
dimensional view. Access to the data needs to be fast if near real-time animation is 
expected. The data structure that is used should be optimal in both space and time. Two 
possible data structures are examined to hold the terrain data required for three tiers of 
resolution. One uses a hierarchical stmcture with pointers. This structure also 
compresses the data. The other uses three two-dimensional arrays and simplifies the 
program to display the terrain at the cost of more storage space. There are problems with 
the transition between different resolutions and the use of z-buffering to display the 
terrain over the water base. Most of the problems have been solved but work is stUl 
needed to refine the techniques and speed up the algorithm. This section is written to 
explain the implementation to readers who might not be familiar with the "tricks" 
commonly used in the C language. 

a. The World 

The database used in this study is divided into cells. Each cell is an area 
one degree latitude by one degree longitude. More then one cell can be displayed at one 
time and as the view point moves the system must be able to change cells. Tlie earth can 
be divided into octants. Each octant consists of 8100 cells in a 90 by 90 array indexed by 
latitude and longitude. This implementation uses one octant indexed from 0 to 90 
degrees north latitude and 90 to 180 degrees east longitude. This matrix is sparsely filled 
with only 30 cells in the database. The array starts out as all null pointers. Pointers to 
individual cell data structures are added as required. The drawing routine checks the 
array for a needed cell. If the pointer is null, the routine initjerrain^ is called with the 



^Appendix F, Appendix G 
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latitude and longitude of the requested cell as parameters. This procedure checks to see if 
the appropriate file is in the database. If not, the ceU is assumed to be all ocean with zero 
elevation at all data points. 

b. Multiple Cells 

The procedure draw_terrain^ first calculates the area that can be viewed in 
the scene. Draw_terrain then sets the view bounds, maximum and minimum coordinates 
in the X and Z direction. The coordinates of the view bounds are relative to the lower left 
comer of the cell containing the view position. The cell containing the view point is 
always drawn. Any view bounds that fall outside the ceU area indicate that another cell 
must be drawn. There are 12 possible cases that are checked with a maximum of four 
ceUs that are drawn for any scene. Figure 5.7 shows an example where four ceUs wUl be 

drawn. The procedure draw_cell^ is caUed once for each ceU. The position of that ceU 
relative to the cell with the view position is passed as a parameter and is used to adjust 
the view bounds to the coordinates of the new ceU. The procedure adjust Jjowids^^ is 
called by drawjcell to do the conversion. 

c. The CeU 

All the actual data for aU three resolutions is stored in ceUs. Tlie data 
structure of the cell is the controlling factor that dictates the efficiency of the drawing 
algoritiuns. 



'Appendix E 

’Appendix F, Appendix G 
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View Bounds forcich resolution arc 
based on the view triangle. 

The view triangle is partitioned into 
three areas , one for each resolution. 
The view bounds arc the max and 
min values that form a square around 
the resolution triangle. 



Figure 5.7 Multiple Cells Drawn With View Bounds 



(1) Initialize the Structure . The data structure for cell data starts out 
empty. When data from a particular cell is first requested, the data must be read from the 
database and inserted into the appropriate structure. The display must pause and wait for 
the data to be entered. The first attempt to read just the raw data into an array took four 
minutes. This is clearly unacceptable. There are a couple of ways to speed-up this 
process. Block reads and self buffering improve the performance, cutting the time down 
to seven seconds. 

In order for block reads to be effective, the database needs to be in 
the same form as the structure it is being read into. The initial data works very well when 
assumptions are made about the way the programming language stores the data. The 
initial data consists of sequential lists of data points. Each list has 1201 two byte integers 
listed sequentially according to ascending latitude. The lists are then stored in order 
according to longitude. The C language stores arrays in this same manner. The name of 
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an array is the address of the first element in the array. The elements in the array are 
stored sequentially in adjacent memory locations. The following line of code read 1201 
two byte words from an input file and stores them sequentially starting at the address of 
Array _name. 

nbyte = fread(Array_name,2,1201,fdi); 

In this way a whole array can be filled with one read. This also works with two- 
dimensional arrays. Array [2], of a two dimensional array, is the address of the starting 
location of the third column in the array. Experiments were conducted to determine the 
most effective buffer size to read this particular data. A buffer size of 28672 bytes was 
chosen. 

The data needs to be in a form that conforms to the data stmcture 
before it is read. Additional preprocessing can also aid the performance. For instance, the 
conversion of data from meters to yards can be accomplished at run time or calculated 
and stored, ready for the program to read. Polygon normals, used for lighting, are another 
example of information that can be preprocessed. 

(2) Drawing the Terrain . Only tlie procedures that actually access die 
elevation data are dependent on the data structure. The procedure that controls the 
drawing of the scene is draw_terrain(f^ This procedure performs the stmcture 
independent tasks and calls the procedure draw_cell ( to access the data and cause the 
proper polygons to be drawn. Draw_cell( ) is stmcture dependent and is covered in the 
following sections on the specific data stmctures. The procedure draw terrain ; 



" Appendix E 

Appendix F or Appendix G depending on the data stmcture 
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* Calculates the visibility 

* Sets the drawing perspective 

* Draws the sky 

* Draws the ocean to the horizon 

* Calculates the area to be drawn in each of the three resolutions 

* Determines what cells to draw 

* Calls the procedure draw_cell() for each of the cells 

Most of the work done by this procedure is in calculating the view bounds that tell the 
procedure draw_cell( ) what part of the cells to display. 

(3) Array Structure . Two-dimensional arrays have properties that 
make them an ideal structure for this application. Each data point can be indexed 
according to its world coordinate location and is accessed in constant time without 
traversing a complicated data structure. The following structure is used to store the data 
for each cell. 

typedef struct! 

short level3[1201] [1201] ; 
short Ievel2[101] [ 101] ; 
short I eve 1 1 [ 1 1 ] [ 1 1 ] ; 

} cell; 

Each resolution is stored in a matrix that can be accessed separately. When a cell not 

already in memory is requested for a scene, the procedure initjerrain^^ allocates 
memory and reads the data into the stmcture. 



'^See Appendix F 
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The procedure 3a.c^“* preprocesses the raw terrain data and writes the 
processed data to a file that can be easily read into the array structure. The data values 
for the different resolutions are calculated in this procedure. Level three resolution is the 
initial data. It is stored as a 1201 by 1201 array. Figure 5.8 is the code that calculates the 
values for the levels one and two data. The level two data is an array 101 by 101 points. 
Each value is the average of the level three points around it. The level one data uses the 
previously calculated level two data to further process the data into the coarser resolution 
of an 1 1 by 1 1 matrix. Because the data points at tlie ceU boundaries are shared between 
cells, the level one and two points at the cell boundary must have the same value as the 
corresponding point in the adjacent cell. This is achieved by using the original data value 
for points around the boundary instead of the averages. The data is written to a sequential 
file in order to make reading the data quick and easy. 

Init_terrain reads in the new data file in the same order it was 
written. The level tliree data is read first, one column at a time followed by the level two 
and level one data. Tliis structure displays one new frame every four to five seconds on 
the IRIS 4D/70G workstation. This time depends on the amount of ocean in the scene. 
More ocean means fewer polygons and less time. 

(4) Pointer Structure . The cells that are of interest in a typical naval 
situation include large areas of ocean containing data points with zero elevation value. 
Polygons are not be drawn for this data when an underlying plane is drawn to represent 
the ocean. It would be nice to preserve the direct access of the array stmcture and cut 
down the space required to store the data structure by not saving all the zeros. The 
following data structure is used to accomplish this. 



See Appendix F 
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/* Level Two Data Calculation */ 
for (i=0;i<=100;i-H-) 

for (j=0;j<=100;j-H-) 

{ 

/* cell boundary points get the value of the underlying point */ 

/* if cell boundary */ 

i£](;(i=0)ll(j=0)ll(i==100)ll(j=100)) 

{ 

level2[i][j]=level3[i*l2]U*12]; 

1 

else 

/* the level three points within 12 data points of the level two 
point are averaged to find the value of the level 2 point */ 

I 

sub=0;/* subtotal */ 

for(s=((i- 1 )* 1 2);s<((i+ 1 )* 1 2);s++) 

for(t=((j-i)*12);t<((j+l)*12);t++) 

( 

sub = sub + level3[s][t]; 

) 

level2[i][j] = sub/576;/* final value avg of 576 points checked */ 

} 

} 



/* Level One Data Calculation */ 
for (i=0;i<=10;i-H-) 

for (j=0;j<=10;j++) 

I 

/* if cell boundary actual value of underlying point*/ 
if((i=0)ll(j=0)ll(i==10)ll(j==10)) 

{ 

level 1 [i][j]=level2(i’'' 1 0][j* 1 0]; 

1 

else 

/* level 1 value is average of underlying level 2 values */ 

( 

sub=0;/* subtotal */ 

foits=((i- 1 )* 1 0);s<((i+ 1)* 10);s++) 

for(t=((j-l)*10);t<((j+l)*10);t-H-) 

{ 

sub = sub + level2[s][t]; 

) 

level l[i]|j] = sub/400;/* final value avg of 400 points */ 

) 

) 



Figure 5.8 Calculation of Level One and Level Two Data 
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t ypede f s t rue 1 1 

shot t data[13][13]; 

1 1 eve 1 3_rec ; 

typedef level3_rec *ptr3; 



typedef structi 

ptr3 level3ptr[ll][ll]; 

short level3val[ll][ll]; 

short a 1 l_ze ro ; 

[level 2_rec ; 

typedef level2_rec *ptr2; 
typedef struct{ 

ptr2 level2ptr[ll][ll]; 

short 1 eve 1 2val [ 1 1 ] [ 1 1 ] ; 

short all_zero; 

1 1 eve 1 l_rec : 

typedef levell_rec *ptrl; 

Each level of data has a separate struemre. The octant that points to 
the individual cells holds pointers to only the level one structure. The level one and level 
two structures have two arrays. One contains the actual data values for the resolution 
while the other contains pointers to the structures for the next level. If an underlying 
structure is all zeros, the structure is not allocated and the pointer is null (see Figure 5.9 ). 

Preprocessing data for this structure is more complex. The data is 
first read into a 1201 by 1201 array. This data is then used to fill in the data structure. 
The level one and two data value can be calculated as either the minimum or the average 
of the points below it in structure. As the data structure is filled, any subceU with all zero 
values is marked not to be saved. The program 3T.c initially uses the raw data to create 
the data structure and then writes it to a file in an order that can be quickly read into the 
structure while the program is executing. 

The level two and three data is basically converted from one large 
array to many smaller arrays. The cell boundaries share data points with adjacent cells. 
This duplicated data is needed in each cell to allow polygons to be drawn to the edge of 
the cell. The same is tme of the sub-cells of level two and three data. The data points on 
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Pointer to cell 




Level one structure 11 points by 11 points 
each position has a value and a pointer 
to the next lower structure 



Boundary points are 
duplicated in adjoining 
structures on all 
three levels. 




Level two subcell. One structure 
for each element in the level one 
structure. Subcells with all zero 
values are not allocated and the 
corresponding pointer in the level 
one structure is null. 

Level three is the high resolution 
data. There is one structure for every 
point in a level 2 structure. 



Level two 

11 points by 11 points 




Level three 
D points by 13 points 




Figure 5.9 Pointer Data Structure 



the edge of the sub-cells must be duplicated in the adjacent subcells and the values must 
be equal. This is done when the data is initially set up in the program 3T.c. 

The values for the level one and level two data were calculated and 
displayed as both the mean value and the low value. Tliere was no discernible difference 
in the display. Since the level one and two polygons are drawn in the distance, a small 
difference in altitude is not significant. 

d. Resolution Transitions 

The transition between resolutions is not smooth. The level one transition 
to level two is in the distance and not noticeable but the line between level two and three 
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shows noticeable gaps where the level three data meets the level two polygon at its end 
points but not at the level three points in between. 

This was solved by drawing a "skirt" around the level two boundary with 
level tlrree. The procedure draw_skirt^^ draws a vertical green plane from the two points 
passed in as a parameter to zero elevation. This procedure is called from the procedure 
draw_cell when a level two polygon is drawn that boarders level three, (see Figure 5.10 ) 

e. Z-buffering 

The use of z-buffering as a hidden surface technique has caused several 
problems in this implementation. The first problem is speed. Each time a pixel is to be 
drawn to fill a polygon its z value must be compared with the pixel value already in the 
z-buffer. If the z value in the buffer is closer then the new point, the buffer stays the same 
and the new point is not drawn. In tliis way a pixel is only changed if the new pixel value 
is in front of the old one. This comparison each time a pixel is written is very expensive 
and time consuming but the algorithm is simplified because the order that the polygons 
are drawn is unimportant. New hardware is supposed to greatly increase the speed of z- 
buffering to a point where it is much faster then trying to keep track of the individual 
polygons. A quick port of the terrain display to the IRIS 4D/GT resulted in an order of 
magnitude improvement. 

Z-buffering caused another problem that affected the resolution 
boundaries. You caimot draw one resolution over another resolution and depend on the 
high resolution polygons always being shown. Tire low resolution data will cover low 
spots or valleys in the high resolution terrain. Since the boundaries cannot overlap, the 



’’Appendix D 
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Resolution Boundary Gap 




Skirt Drawn To Fill The Gap 
Figure 5.10 Resolution Boundary 
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lower resolution must be drawn out to the boundary of the next higher resolution. The 
bottom line is that more polygons must be drawn, and the program must do more 
calculation to compute the boundaries. 

Z-buffering does not always work correctly when two parallel planes are 
drawn close to each other. When the terrain is drawn over one blue polygon representing 
the ocean, the shoreline and the ocean are basically two parallel planes that often map to 
the same pixel and z-buffer location. The pixel value that is drawn is unreliable. The 
effect is popping blue splotches on the terrain as tlie view point changes. Figure 5.11 
shows two pictures of the same area taken at different elevations. As you can see, tlie 
shape of the shoreline changes and is not regular. 

There are two solutions to this problem that don’t require that more 
polygons be drawn. Drawing the ocean before or after the terrain has no effect. The z- 
buffering seems to work better close to the near clipping plane. Moving the near clipping 
plane forward as far as possible helped some but did not solve the problem. Another help 
was changing the far clipping plane to be one and a half times the visibility. This in 
effect decreases the resolution in the z direction but the picture quality is improved 
slightly. It was suggested that at least 20 bitplanes are required for the z-buffer [Ref. 13]. 
The IRIS 4D/70G has 24 bitplanes but due to a software problem only 16 can be 
accessed. The new IRIS 4D/GT can now access all 24 bit-planes. Preliminary tests on the 
new machine indicate that the z-buffer resolution is not the cause of this particular 
problem. The final part of this solution was to lower the water a distance that is about one 
pixel below the land. This causes enough separation to insure that the land is drawn over 
the water. A distance of six yards worked well for the level two and three data. There is 
still some problems in the background but the overall picture is good (see Figure 5.12 ). 
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Figure 5.11 Z-buffer Changing Coastline 
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Figure 5.12 Picture With Corrections to Z-buffering 



There is anotlier way to solve this problem if you don’t need hidden 
surface elimination for anything drawn under the water. Turn z-buffering off before 
drawing the ocean plane. Then turn z-buffering on, clear the z-buffer, and draw the 
terrain. This insures that everything will be drawn over the ocean plane. This won’t cause 
a problem unless the intention is to draw additional objects that might Lie partially under 
water, i.e. ships. 

Another solution to this problem requires that polygons be drawn for the 
ocean. This separates the sea and land so they are not drawn as two parallel planes. This 
solution takes more time to draw the extra polygons. If the hierarchical structure is used, 
the complexity of the program increases because of the null pointers. 'Hie program must 
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detenniiie what size the polygons are and where to draw them when a null pointer is 
encountered. This is still better then drawing all the water polygons for the standard 
resolution because only one polygon needs to be drawn for each null pointer. 

D. CONCLUSIONS 

1. Data Structures 

The Array structure requires about 3 megabytes of data. The pointer requires 
about 0.8 megabytes for an average cell, about half water half land. The procedures for 
the initialization and drawing the structure are much more complex with the pointer 
system. The time required to draw one frame is three to five seconds for the array and 
one to five for the pointers. At worst case, when the scene is all land, performance is 
about equal. The pointer system excels when the viewpoint is over water and null 
pointers are encountered when drawing. The performance of the hierarchical pointer 
structure is at worst the same as the array. The improvement when drawing both land and 
water make the increased complexity of the hierarchical pointer version of the program 
worthwhile. 

2. Z-buffering 

Z-buffering is not always the best solution to the liidden surface problem. 
Many of the problems with displaying the terrain would be greatly reduced if the 
painter’s algorithm was used instead. If the end use of this research was to just display 
terrain the painters algorithm would be acceptable. The difficulty comes when you want 
to add objects to the display, i.e. ships, tanks, buildings, etc. The painter’s algorithm relys 
on the drawing order of the polygons. The polygons closest to the viewpoint are drawn 
last covering any objects farther away. Any objects that are drawn in addition to the 
terrain must have their polygons sorted with the terrain polygons to insure that all the 
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polygons that represent the final picture are drawn in order, far to near. See [Ref. 7] for 
a better discussion of this technique. If the problems with z-buffering can be overcome, 
it is well worth the effort for a three dimensional display. 

Black and white unages are used throughout this chapter to Ulustrate points 
about the display. Figures 5.13 and 5.14 are color photographs of typical views seen in 
the three-dimensional terrain display. They are added to help equate the black and wliite 
images to the views actually seen on the system’s color display. 
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Figure 5.14 Color Photos of the Terrain Display 
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Figure 5.15 Color Photos of the Terrain Display 
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VI. CONCLUSIONS 



A commander’s workstation that provides useful information in a way that is easy to 
understand and control is not only feasible but essential for managing the vast amount of 
information a commander needs to make speedy, well informed decisions. This study 
focuses on two preliminary issues in the development of the command and control 
workstation of the future (CCWF), a user interface with multiple windows and a three- 
dimensional display of the sea/land environment. 

A. THE USER INTERFACE 

Multiple windows is a necessity. Separate, physical displays for each type of 
information is not practical. The use of multiple windows as virtual displays allows the 
user to quickly and easily arrange the screen to show the information that is required. 

A mouse or track-ball controlled cursor is an easy way to control the entire 
workstation. The user can "point and click" to perform any operation without having to 
fumble with unfamiliar switches and dials. 

Controls that are presented on the screen in pop-up menu form are easier to 
understand and execute. After the selections have been made, the menu disappears untU 
it is needed again. The menus are changed according to the situation. Only the 
executable subset of actions is presented to the user. This gives the user fewer choices to 
sort through before making a selection. The selections are presented on the screen in 
simple easy to understand English. Operations that are infrequently executed are 
presented in a separate menu that is called from the main menu. This is an effective way 
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to change default system settings. Menu driven controls increase the effectiveness of tlie 
user interface with the CCWF. 

B. THREE-DIMENSIONAL DISPLAY 

A three-dimensional display is very complex. It requires a very powerful computer 
capable of drawing on the order of 100,000 polygons per second. This study focuses on 
the display of digital terrain elevation data in a three-dimensional display. 

Data from the Defense Mapping Agency standard tapes is used. Appendix C shows 
the routines developed to extract files from the DMA standard tap>es and also the routines 
developed to extract the needed information from the files. 

The terrain is drawn by passing elevations for four adjacent points to a routine that 
draws two triangles representing the area between the four points. An acceptable 
approximation of the actual shoreline can be generated by assuming that any square with 
three of the points at zero elevation has one triangle land and one water. Any square with 
all zero elevations is all water and any other combination is all land. 

Objects in the distance are seen in less resolution then objects that are close. A 
teclmique that models this natural fact is to use tliree resolutions of terrain data. A high 
resolution data with points close together, is used to draw terrain in the foreground. A 
medium resolution has points that are farther apart and a low resolution is used to draw 
things far away. 

A hierarchical stmcture with pointers works very well to store tlu'ee resolution 
terrain data. The data is stored in small stnictures starting with low resolution on top and 
working down three layers to the high resolution data. The value of each low resolution 
point is based on the values of all the higher resolution points below it in the structure. 
This teclinique also compresses the data. A command and control workstation for the 
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Navy is primarily concerned with the area of sea and land. Many of the data values for 
these cells are zero in elevation, indicating ocean. Any sub cell with all zero values is 
not stored. The structure that represents this area is not allocated and the pointer to this 
section is null. When a null pointer is encountered while drawing the terrain the system 
knows all values below this point are zero. 

Z-buffering was used as the means of hidden surface elimination. This method 
makes drawing many polygons very easy but is very costly in time. It is hoped that 
future hardware improvements will overcome the problems and allow z-buffering to live 
up to its potential. 

C. FUTURE WORK 

Tlie next step in the development of CCWF is to combine the multiple window 
interface with the three-dimensional display. New hardware, the IRIS 4D/GT, provides 
the computation and graphics power needed to provide multiple, separately controlled 
windows, showing two and three-dimensional views in near real-time. The two- 
dimensional version of the command and control workstation needs to be ported to the 
new hardware and changed to conform more closely with the native window manager. 
The three-dimensional terrain display should be included in the new system. 
Enhancements needed in the two-dimensional display include information on the closest 
point of approach, track history and other common NTDS functions. The ability for the 
user to enter information directly into the system should also be added. This can be used 
to enter contacts into the system or show special marks or boundary areas on the display. 
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A new display showing a map of the region needs to be developed. Terrain elevation 
data is available and cultural data can be obtained from DMA. NTDS symbology should 
be shown on the display indicating contacts. 

All three of these displays need to be tied together, sharing the same information. 
Tire database of contact information needs to be expanded to include a three-dimensional 
graphics representation that can be displayed and selected in the three-dimensional 
display. The view point of the three-dimensional display should be set by selecting a 
contact or a point in the NTDS or chart display. 

Work is needed in the three-dimensional display to take advantage of the additional 
power provided in the IRIS 4D/GT. A lighting model should be added to provide more 
realistic views with Gouraud shading. Contacts, buddings and special features should be 
represented by special three-dimensional icons that resemble the actual objects. More 
accurate drawing bounds can be computed, cutting the number of polygons that are 
drawn. 

The user should be able to attach to a contact and see the view from the perspective 
of someone on a ship’s bridge or in a plane’s cockpit. The view-point should also have 
the abUiry to be free floating, where the user selects a position and then moves about at 
wUl. The user selects a contact in fomiation to attach to. WhUe attached, the view shown 
on the three-dimensional display is based on the position, course and the height of eye of 
the contact. Tlie user then detaches from the contact. He can assign a course and speed 
to the view point and move about, observing the fonnation from any angle. 

Tactical information, such as weapons and sensor envelopes, can be added to the 
three-dimensional display. The user selects a contact and asks for the weapons systems to 
be displayed. A window opens with a list of weapons and sensors. The user then asks to 
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see the envelopes of all or some of the systems. The area that is effected on the three 
dimensional display is overdrawn with a transparent color showing the effective area. 

The information available in Defense Mapping Agency cultural files can be added to 
both the two and three-dimensional displays. The chart display can show features 
commonly found on maps and charts, i.e. cities, landmarks, buddings, towers, 
navigational aids, etc. The three-dimensional view can use three-dimensional icons to 
represent these same features. 

A system with all of the features listed above is a major effort. In fact we foresee 
that even greater graphics capabilities are needed to completely carry out our desires for 
the three-dimensional display. Fortunately, we see near future graphics workstations that 
will give us an order of magnitude increase in polygons per second in the next two years. 
Before that time we need to prototype and explore three-dimensional capabilities with 
the hope that we are able to provide a prototype of the command and control workstation 
of the future, as the new hardware arrives. 
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APPENDIX A - DEFENSE MAPING AGENCY TAPES 



Tape 1 


Tape 2 


six cells 


six cells 


30N 129E 


32N 128E 


30N 130E 


32N 129E 


30N 131E 


32N 130E 


31N 129E 


32N 131E 


3 IN 130E 


32N 132E 


31N 131E 


32N 133E 


Tape 3 


Tape 4 


eight cells 


nine cells 


33N 126E 


33N 125E 


33N 127E 


33N 126E 


33N 128E 


33N 127E 


33N 129E 


33N 128E 


33N 130E 


33N 129E 


33N 13 IE 


33N 130E 


33N 132E 


33N 131E 


33N 133E 


33N 132E 
33N 133E 
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APPENDIX B - DIGITAL TERRAIN ELEVATION DATA FORMAT 



This is the file discription for the Defense Mapping Agency digital terrain elevation 
data used in this project. It was extracted from the Defence Mapping Agency publication 
"Product Specifications for Digital Landmass System (DLMS) Database", stock number 
SPEXDLMS2. 



CHAPTER tf - DIGITAL FILE DESCRIPTIONS 
SECTION 100 — TERRAIN 



Paragraph Page 

101 General 81 

102 File Characteristics 81 

103 Record Formats 86 

104 Explanation of Records and Fields (DIED) 96 



101. General 

The DMA Standard Terrain Format is DMA's standardized system of recording 
terrain elevation data on magnetic tape. The format is intended for the purposes of 
production, storage and exchange of terrain elevation data. 

102. File Characteristics 

A. Physical Characteristics of Magnetic Tape 

1. Length: 2400 feet 

2. Width: .5 inch 

3. Nine track recording format 

4. Odd parity 

5. Density/recording method: 

a. 1600 FPl/Pnase encoded. This is preferred by DMA for storage and 
data exchange and will normally be expected from generators and provided to requestors. 

b. 800 FPl/NRZL This is not preferred by DMA but will be provided to 
or accepted from data requestors or generators unable to accept or generate 1600 FPl, 
phase encoded data. 



c. 6250 FPl/GCR. Future preferred DMA data exchange format* Will 
not be used unless agreed to by sender and receiver. 

6. Inter-Record gap: .6 inch (6250 FPl: .3 inch) 

7. Physical end-of-tape markers at ’ the beginning (beginning -of-tape 
marker) and end of the tape (end-of-tape marker). 
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B. Record Characteristics 

1. Recorded Labels: American National Standard Magnetic Tape Labels for 
Information interchange X3.27 - 1969, Recorded in ASCII code. 

2. Data Records: 

a. Record size: variable length, maximum 14414 frames, minimum 14 
frames, modal (average) 2414 frames. 

b. Blocking factor: 1:1 (block size = record size) 

3. Record Sequence: 

VOL 1 (Volume Header Label) 

HDR 1 (File Header Label for file A) 

UHL 1 (User Header Label for file A) 



DSi (for file A) 
ACC (for file A) 
Data (for file A) 



EOF 1 (End of File for file A) 

UTL I (User Trailer Label for file A) 



HDR 1 (File Header Label for file B) 
UHL 1 (User Header for file B) 



DSi (for file B) 
ACC (for file B) 
Data (for file B) 



EOF I (End of File for file B) 

UTL 1 (User Trailer Label for file B) 



In the above sequence, a Tape Mark (hardware end of file) is denoted by an 
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4. Logical Characteristics: {Level 1) 



a. Data File Structure: Arranged into 1 degree by 1 degree 

geographic areas. Each data file will contain data falling within a single one 
degree square. The reference origin for each data file will be the Southwest 
corner of the degree square. Multiple data files will be arranged primarily by 
ascending latitude bands (-90° South to +90° North), secondarily by ascending 
longitude (-180° West to +179° East). 

.. b. File Extent: To provide overlap between adjacent data files, 
the degree square coverage in this standard includes the even degree values on 
all sides of the area. Each data record has one point of overlap with the 
square above and one with the square below (if the record extends to the 
degree square limits). Entire data records lying on integer degree longitude 
values will also exist in the adjacent degree square. 

c. Terrain Elevation Intervals: The horizontal plane spacing of 
the elevation array will be in whole second intervals for intervals of 
1 second and above and in 0.1 second intervals for intervals less than 
1 second. 



d. Data Value Sequence: The elevations within a data record have 
a constant longitude value. The first data value is the southernnost known 
elevation and the last is the northernmost. Unknown values internal to the 
record are indicated by the null state condition of all one-bits. No two data 
records will have the seune longitude value. 

e. Data Record Sequence: Within a data file, the records are 

arranged in order by ascending longitude. 

f. Hash Control Total Information: The last four frames of each 
type data block contain a 32 bit value which is a checksum computed algebraic- 
ally by suaning all elevations and header words in that block, as 8-bit values 
using integer arithmetic. Each frartis from tape is considered as an 8-bit value 
for checksum calculation. 

5. Field Characteristics: 

a. Numeric Value: All elevation values are signed magnitude 
binary integers, right justified, 16 bits. The sign is the high order posi- 
tion. Negative values are not complemented. 

b. Permissible Elevation Value: ^32767 meters 

NOTE: This is the maximum allowable elevation value. However, this value will 
not exceed +9000 meters or -12,000 meters. 

c. Null State Condition: Blank data will be all one bits. 

6. Explanatory Diagram: In order to more fxilly explain the file 
structxire, figure 4-100-1 is included. 
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FIGURE 4-100-1 
TERRAIN EXAMPLE 
FOUR 1® CELLS 
12* LONGITUDE SPACING 
(NON STANDARD) 
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Figure 4-100-1 
TERRAIN Example (Continued) 
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NOTES: 



( 1 ) 



In above example 
each Data Record 
Data Record contains 



(non-standard 12* LatitudeA»ongitude 
contains 6 elevations. A 3" standard 
1201 elevations. 



spacing), 
1^ square 



(2) Elevations along 1® boundaries are repeated for each 1^ square. 
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103. Record Formats 

Digital Terrain Elevation Data. See Section 104 for further explanation 
of Records and Fields. 

In the following record formats, a character requires one frame or 
8 binary bits. 

% 

K. VOL Header Label 



Field Contents 


Field Length 
In Characters 


Description 


VOL 


3 


Recognition sentinel 


1 


1 


Fixed by standard 




6 


Reel Number 

Six alphanumeric characters 
identifying the physical reel 


Blank or Nonblank 


1 


♦Nonblank indicates restricted 
access, as the tape reel is 
privately owned 


Blanks 


26 


Unrequired available space 


Account Number 


14 


♦Account number of owner of 
this tape reel (DMA uses a 
maximu\n of 12 characters 

left-justified, space filled) 


B lanks 


28 


Fixed by standard 


1 


1 


Fixed standard 



♦These fields, to be defined by the producer, may be left blank. 



B. HDR Header Label 



P^ield Contents 
HDR 
1 

Fi lename 



Field Length 
In Characters 

3 

1 

17 



Descript ion 

Recognition sentinel 

Fixed by standard 

♦Lef t- justl f ied filename. The 
first 12 characters are 
referenced by the Executive 
System for comparison with the 
filename portion of the 
external filename. 
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Field Contents 



Field Length 
In Characters 



Description 



UNIVAC 6 

000 1 4 

0001 - NNNN 4 

0001 4 

00 2 

bYYDDD 6 



bYYDDD 6 



A sp>ace indicates unlimited 1 

access to this reel 



♦Fixed as set identifier when 
referenced by system, 

♦Reel sequence number within a 
file. 

♦File sequence number within a 
reel. 

♦Generation and version numbers 
which are fixed at 1 and 0. 

Creation date of tape. A blank 
followed by two characters for 
the year followed by three 
characters for the day (00 1 
through 366) within the year, 
(date tape was written) 

♦Expiration date of tape. Same 
format as creation date field. 
The date after which this tape 
reel may be considered as avail- 
able for reallocation. 

♦Accessibi li^y 



15g - This reel is catalogued 
(on tape). 

350 - This reel is catalogued 
with read key. 

55g - This reel is catalogued 
with write key. 

750 - This reel is catalogued 
with read and write key. 

Block Count 6 ♦Fixed at zeros. 



Qualifier 13 ♦Used by the Executive Operating 

System (DMA uses a maximum of 
12 characters left- justified 
space filled). 

Blanks 7 Fixed by Standard. 

♦These fields to be defined by the producer may be left blaink. 
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C. User Header Label 



Field Length 
In Characters 



Field Contents 



Description 



UHL 3 

1 1 

% 

DODMMSSH .. 8 



DDDMMSSH 



8 



SSSS 



4 



SSSS 



4 



0000-9999 or NA 



4 



T - Top Secret 3 

S - Secret 
C - Confidential 
U - Unclassified 
R - Restricted 

Unique reference 12 

number 



Number of longitude lines 4 



Recognition sentinel 

Fixed by standard 

Longitude of origin (lo%#er left 
corner of Square-full 

degree value). H is the 
Hemisphere of the data. 

Latitude of origin (lo%#er left 
corner of Square- full 

degree value). H is the 
Hemisphere of the data. 

Longitude data interval in 
seconds (Decimal point is 
implied after third integer). 

Latitude data interval in 
seconds (Decimal point is 
implied after third integer). 

Absolute Vertical Accuracy in 
meters. With 9 0% assurance that 
the linear errors will not exceed 
this value relative to mean sea 
level. (Right justified) 

Security Code (Left justified) 



♦Unique reference number (provide 
pointer to file containirfg detailed 
file description) 

Count of the number of longitude 
(profiles) lines 
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} 



Field Contents 



Field Length 

In Characters Description 



Number of latitude 
points 



♦Count of the number of latitude 
points per longitude line. Since 
the current implementation allows 
for variable record size, this 
field has very limited use. 



Multiple accuracy 



0 - Single 

1 - Multiple 



Reserved 24 Unused portion for future use 

♦These fields to be defined by the producer may be left blank. 



D. Data Set Identification (DSI) Record 
Fixed Length = 648 * characters (Bytes) . 

Each Character = 1 Tape Frame = 8 Bits 

Field Length 

Field Contents In Characters Descript ion 



DSL 3 

T - Top Secret 1 

S - Secret 
C - Confidential 
U - Unclassified 
R - Restricted 

2 



27 



26 

DTEDl or 5 

DTED2 

15 



01-99 

A-2 



8 

2 

1 



YYMM 



4 



Recognition Sentinel 
Security Classification Code 



Security Control 2 md Release 
Marking. For DoD use only 
(DIAM 65-19) 

Security Handling Description 
Other security description 

Reserved for future use 

DMA Series Designator for 
product type 

Unique reference number (For 
producing nations own use or 
zero filled) 

Reserved for future use 

Data Edition Number (01-99) 

Match/Merge Version (A-2) 

Maintenance Date (2ero filled 
until used, ) 
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Field Contents 



Field I>ength 
In Characters 



Description 



YYMM 4 

4 

C*CAAABBB 8 

< Country Agency Branch) 

16 

9 



♦ 00 or 01-99 2 

4 

^'ISL 3 

^'^GS72 5 



10 

YYMM 4 

22 



DDMMSS.SH 9 
ODDMMSS . SH 10 
DDMMSSH 7 

DDDMMSSH 8 



Match/Merge Date 

Maintenance Description Code 
(All zero filled) 

Producer Code (DIA Country Codes 
used for first 2 characters) 

Reserved for future use 

Product Specification Stoc)c 
Number (SPEXDLMS2) 

Product Specif ication 
Amendment and Change Number 

Product Specification Date 
(Currently 8304) 

Vertical Datum (Mean Sea Level) 

Horizontal Datum Code 
(World Geodetic System 1972) 

Digitizing Collection System 

Compilation Date (Most 
descriptive month/year) 

Reserved for future use 

Latitude of origin of Data. 

H is the hemisphere of data. 

Longitude of origin of Data. 

H is the hemisphere of 'data. 

Latitude - SW corner of bounding 
rectangle. H is the hemisphere 
of the data. 

Longitude - SW corner of bounding 
rectangle. H is the hemisphere 
of the data. 
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Field Contents 



Field Length 
In Characters 



Description 



DDMMSSH 7 
DDDMMSSH 8 
DDMMSSH 7 
DDDMMSSH 8 
DDMMSSH 7 
DDDMMSSH 8 
DDDMMSS.S 9 
SSSS 4 



SSSS 4 



0-9999 4 



0-9999 4 



Latitude - NW corner of data, 
bounding rectangle. H is the hemi- 
sphere of the data. 

Longitude - NW corner of data, 
bounding rectangle. H is the hemi- 
sphere of the data. 

Latitude - NE corner of data, 
bounding rectangle. H is the hemi- 
sphere of the data. 

Longitude - NE corner of data, 
bounding rectangle. H is the 
hemisphere of the data. 

Latitude - Sc corner of data, 
bounding rectangle, H is the 
hemisphere of the data. 

Longitude - SE corner of data, 
bounding rectangle. H is the 
hemisphere of the data. 

Clockwise orientation of data with 
respect to true North (will usually 
be all zeros for DTED). 

Latitude interval in tenths of 
seconds between rows of elevation 
values (Decimal point is implied 
after third integer). 

Longitude interval in tenths of 
seconds between columns of eleva- 
tion values (Decimal p>oint is 
implied after third integer). 

Number of Latitude lines 
Actual count - Number of 
latitude points, (rows that 
^ contain data) 

Number of Longitude lines 
Actual Coxint - Number of 
longitude points (columns 
that contain data) 
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Field Length 

Field Contents In Characters 


Description 


♦ 00 or 01-99 2 


Partial Cell Indicator 

00 = Complete 1® square 

01-99 = % of coverage completed. 


10 1 


Reserved for DMA use only. 


100 


Reserved for producing nation 
use only. 


156 


Reserved for future use. 


E. Accuracy Description (ACC) Record 





Fixed Length * 2700 characters (Bytes) 
Each Character = 1 Tape Fraune = 8 Bits 



Field Length 

Field Contents In Characters 


Description 


ACC 3 


Recognition Sentinel 


* 0000-9999 or NA 4 


♦Absolute Horizontal Accuracy 
of Product in meters. NA if 
not specified. 


* 0000-9999 or NA 4 


♦Absolute Vertical Accuracy 
of Product in meters. NA if 
not specified. 


* 0000-9999 or NA 4 


♦Relative Horizontal Accuracy 
of Product in meters. NA if 
not specified. 


* 0000-9999 or NA 4 


♦Relative Vertical Accuracy 
of Product in meters. NA if 
not specified. 


• 4 


Reserved for future use. 


* 1 


Reserved for DMA use only. 


* 31 


Reserved for future use. 


* 00 or 02-09 2 


Multiple Accuracy Outline Flag 
00 - no outline provided 
02-09 =* number of accuracy 
subregions per square 

(raaxinum 9) 



'If Product has subregional accuracies, the overall accuracy of the product will be 
the worst accuracy. 
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Field Contents 



Field Length 
In Characters 



Descr iDt ion 



Start of Accuracy Subregion Description. Repeat 
to maximum of nine times. Blank fill all unused 
accuracy subregions. 



* 0000-9999 or NA 4 

* 0000-9999 or NA 4 

* 0000-9999 or NA 4 

* 0000-9999 or NA 4 

* 03-14 2 



Absolute Horizontal Accuracy 
of subregion in meters. NA 
if not specified. 

Absolute Vertical Accuracy 
of subregion in meters. NA 
if not specified. 

Relative Horizontal Accuracy 
of subregion in meters. NA 
if not specified. 

Relative Vertical Accuracy 
of subregion in meters. NA 
if not specified. 

Number of coordinates in accu- 
racy subregion outline. (Maximum 
of 14 coordinate pairs. Coordinates 
are input clockwise. Implied 
closing from last to first 
coordinate pairs. ) 



Start of Coordinate Pair Description. Repeat to 
maximum of fourteen times to outline subregion. 
Blank fill all unused accuracy subregions. 

DDMMSS.SH 9 Latitude. H is the hemisphere 

of the data. 

DDDMMSS.SH 10 Longitude, H is the hemisphere 

of the data. 

End Coordinate Pair Description 



End Accuracy Subregion Description 



# 


18 


Reserved 


for 


DMA use only. 


* 


69 


Reserved 


for 


future use. 
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F. 



EOF Trailer Label 



Field Contents 



Field Length 

In Characters Description 



EOF 

1 



3 Recognition Sentinel 

1 Fixed by standard 

(See HDR header label for remainder of EOF fields.) 

G. UTL Trailer Label 



Field Length 

F ield Contents In Characters Description 

tlTL 3 Recognition Sentinel 

1 1 Fixed by standard 

(See user header label for remainder of UTL fields. ) 

H. Data Record Description 

Each element is a true elevation referenced to mean sea level datum 
recorded to the nearest meter. The horizontal position is referenced to specific 
longitude- latitude locations in terms of the World Geodetic System (WGS), deter- 
mined on each file by reference to the origin at the Southwest corner. The elements 
are evenly spaced in latitude and longitude at the interval designated in the user 
header label in South to North profile sequence. 



Field Contents 



Field Length 
In Characters 



25 2e W 1 

Data block count 3 



Longitude count 



2 



Description 



Recognition sentinel 

Sequential count of the block 
within the file, starting with zero 
for the first block (Fixed Binary) 

Count of the meridian. True 
longitude = longitude count X data 
interval + Origin (S.W. corner) 
(Fixed Binary) 
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I 



Field Contents 


Field Length 
In Characters 


Description 


Latitude count 


2 


Count of the parallel. True latitude = 
latitude count X data interval origin 
(S.W. corner) (Fixed Binary) 


Elevation 1 


2 


True elevation value of point 1 of 
meridian in meters (Fixed Binary) 


Elevation 2 


2 


True elevation value of point 2 of 
meridian in meters (Fixed Binary) 


Elevation N 


2 


True elevation value of point N of 
meridian in meters (Fixed Binary) 


Checksum 


k 


Algebraic addition of contents of 
block. Sum is computed as an 
integer summation of 8-bit values 
(Fixed Binary) 



NOTE:Fixed Binary denotes signed magnitude, right-justified binary integers. 
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104. EXPLANATION OF RECORDS AND FIELDS (DIED). The iollowing explanation 
of Records and Fields supplements, where necessary, the descriptions shown in Section 
103. 

A. VOL Header Label- 

This record is required for labeled tapes in accordance with ANSI standard 
X3.27-1969 Magnetic Tape Labels for Information Interchange. 

B. HDR Header Label. 

This record is required for labeled tapes in accordance with ANSI standard 
X3.27-1969 Magnetic Tape Labels for Ir.iormation interchange. 

C. UHL User Header Label. 

1. ANSI standard allows an optional user header label in the first file of a 
labeled tape. Several computer manufacturers have implemented tape laoeiing in such a 
way that the user header label in the first file of the tape is inaccessible. This record is 
maintained for minimum impact to users not desiring to use the DSI record, but all 
information in it is in the DSI record as well. 

2. Fields. 

a. Longitude of Origin - Origin is always a full degree value even 
though the format allows values to be expressed to the second. 

b. Latitude of Origin - Origin is always a full degree value even though 
the format allows values to be expressed to the second. 

c. Seconds Longitude Interval - A square of DTED is North-South 
oriented with columns of elevation posts running from south to nortn. The longitude 
interval is the East-West distance between the columns expressed as tenths of seconds. 

d- Seconds Latitude Interval - The spacing between the elevation posts 
within a column (i.e., the distance betv/een the rows) is the latitude interval. 

e. Accuracy - The accuracy of the product in meters. 

D. Data Set Identification (DSI) Record (DTED). 

1. This record provides all identification and security information related 
to the product except accuracy information. It duplicates information from the Header 
Record so that users may process the data using only the information in the DSI record if 
desired. 
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2. Fields. 



a. Security Control and Release Markings - The two character 
codes are from DIAM 65-19. 

b. DMA Series Designator - Five character code identifying the 
product in DMA Area Requirements and Product Status (ARAPS) file. 

*c. Unique Reference Number - to be detennined. 

d. Data Edition Number - The number assigned to the data 

indicating either origir^l compilation (Edition 1) or subsequent replacements 
of the data (Editions 2 , 3 , etc.) to aciiieve accuracy requirements (recompi- 

lation) or currency/specification requirements (revision). The data edition 
number does not reflect the number of replacements made to the data to effect 
boundary matches. 

e. Match/Merge Version - The number of times an edition of the 
data was changed to effect boundary continuity with adjacent data in the 
Cartographic Data Base (CDB). 

f. Maintenance Date - The date existing data was either revised 
(updated) to meet the currency requirements (or to effect specification 
changes), or recompiled to meet accuracy requirements . When the existing data 
is only revised (horizontal position or vertical values are not significantly 
changed) the maintenance date will reflect the date of the revision, but the 
compilation date will not be changed — it will continue to reflect the date 
of the original compilation. However, when the data is subjected to a major 
recompilation, the Compilation Date and the Maintenance Date will both be 
changed to reflect the date of the recompilation. 

g. Match/Merge Date - The latest date the data was changed to 
effect contimity with adjacent data. This data corresponds to the Match/Merge 
Version Code. 



h. Maintenance Description Code - to be determined. 

i. Producer Code - The first two characters (left justified) 
indicate the producing nation and are from DIAM 65-18 - Geopolitical Elements 
and Related Files. The last six characters are to be used at the discretion of 
the producer. Blanks are acceptable. 

Belgium BE Netherlands NL 

France FR Norway NO 

Germany, Federal Republic of GE United Kingdom UK 

Italy IT United States US 

j. Product Specification Stock Number - Identifies the product 
specification containing the compilation and accuracy requirements used to 
produce the data. Currently SPEXDLMS2. 
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k. Prcxiuct Specification Amendment and Change Number - Indicates 
the highest numbered amendment and change used to produce the data (Amendment 
0, change 1 — 01; Amendment 2, change 2 — 22; etc.). 

l. Vertical Datum Code - Currently MSL. 

m. Horizontal Datum Code - Currently WGS72. 

n. Digitizing Collection System - Identifies the equipment used 
to collect the cartographic values from the source material used, i.e., AGDS, 
LIS, UNAMACE. 



o. Compilation Date - The date the data was either originally 
compiled (Edition 1) or the date existing data was subjected to a major 
recompilation which involved significant changes to the horizontal positions 
and vertical values. (Edition 2, 3, 4, etc.) 

p. Latitude of Origin - Expressed in degrees, minites, seconds 
and tenths of seconds with N or S to indicate hemisphere. 

q. Longitude of Origin - Expressed in degrees, minutes, seconds 
and tenths of seconds with E or W to indicate hemisphere. 

E, Accuracy Description Record. 

The accuracy record gives the accuracy of the product. The record 
allows space for the delineation of xxp to nine accuracy regions within the 
product should the accuracies of various portions of the product differ. Each 
outline may have to fourteen coordinate pairs. Coordinates are input 

clockwise. The record is a fixed length record. Unused coord imte pairs are 
blank filled. 
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APPENDIX C - ROUTINES TO USE DMA DIGITAL TERRAIN DATA 



The two programs in this appendix are for manipulating Defense Maping Agency 
digital terrain elevation data. The first, dted.c, reads one file at a time from the standard 
DMA magnetic tape. The name of the output file is passed as a command line argument. 
The program is repeatedly called with new names until the entire tap>e has been read. 

The second program takes a data file extracted from the DMA tape and extracts the 
just the data from the file and writes it to a file whos name is the Latitude and longitude 
of the southwest comer of the cell. 



* FnName: dted.c 

* Author: FRANK HARRIS 

* Date: Jan 88 

* Purpose: to read dma dted tapes onto isivl 



#include <sys/file.h> 

#define maxsize 3000 
#define FALSE 1 
#defineTRUE 0 
main(argc,argv) 
int argc; 
char *argvQ; 

{ 

int fdi, fdo, nbyte; 
char buf[maxsize]; 
short endfile ; 

/* open tape */ 

/* tape not reset after each call */ 

/* will open the tape where it was last stopped */ 
if((fdi=open('7(2>isiv8/dev/snrmt0",O_RDONLY)) < 0) 

{ 

printf( "cannot open tapeO); 
exitO; 

} 

/* open output file, filename passed into program as argv param */ 
if((fdo=creat(argv[l], 0666)) < 0) 

I 



printfC'cannot open data fileO); 

endfile = FALSE; 

exitO; 
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/* read the next file file on the tape */ 
while(!endfile) 

i 

nbyte=read(fdi,buf,maxsize); 
Lffnbyte < 0) 

printfC’read errorO); 
if(nbyte == 0) 

{ 

printf("end of fileO); 
endfile = TRUE; 
exitO; 

I 

nbyte = write(fdo,buf,nbyte); 

} 

close (fdi); 
close (fdo); 
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* FnName: extract.c 

* Author: FRANK HARRIS 

* Date: jan 88 

* Purpose: to extract terrain data from DMA file 

#include <stdio.h> 

#include <string.h> 

#include <sys/types.h> 

#define maxsize 3000 
#define FALSE 0 
#defineTRUE 1 
#define buf_size 28672 
char *BUF,*BUFO; 
int row.ij; 
char *malloc(); 

FILE *fdi*fdo; 

main(argc,argv) 
int argc; 
char *argvQ; 

I 

int j,i,n,nbyte; 
char name [9]; 
char c[2]; 
char buf[maxsize]; 

/* open input file */ 
if((fdi=fopen(argv[l],"r")) < 0) 

I 

printf("cannot open fileO); 
exitO; 

) 

/* set up input buffer */ 
if ((BUF=malloc((buf_size )+l)) == NULL) 

I 

fprintf(stderr,"out of memoryO); 
exit(l); 

) 

setvbuf(fdi,BUF,_IOFBF,buf_size ); 

/* skip to lat long */ 
fseek(fdi, 185,0); 

/* extract lat long for filename */ 
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/* use bytes 185,186,193,194,195,196,203 */ 
cll]=’ 

nby te=fread(c, 1 , 1 ,fdi); 

name[0]=c[0];nante[l]=’ 

nbyte=fread(c,l , 1 ,fdi); 

strcat(name,c); 

fseek(fdi,193,0); 

nbyte=fread(c,l ,1 ,fdi); 

strcat(name,c); 

nby te=fread(c,l , 1 ,fdi); 

strcat(name,c); 

nby te=fread(c, 1 , 1 ,fdi) ; 

strcat(name,c); 

nbyte=fread(c,l , 1 ,fdi); 

strcat(naine,c); 

fseek(fdi,203,0); 

nbyte=fread(c,l ,1 ,fdi); 

strcat(name,c); 

/* skip to first data record */ 
fseek(fdi, 3348,0); 

I* open output file */ 
if((fdo=fopen(name,"w")) < 0) 

{ 

printf("cannot open output fileO); 
exitO; 

) 

/* allocate space for buffered I/O */ 
if ((BUFO=malloc((buf_size )+l)) = NULL) 
{ 

fprintf(stderr,"out of memoryO); 
exit(l); 

) 

setvbuf(fdo,BUFO,._IOFBF,buf_size ); 

for( i= 1 ; i<= 1 20 1 ; i++) 

{ 

/* skip recog sym and record header */ 
nbyte=fread(buf, 1 ,8 ,fdi); 

/* read & write data */ 
nbyte=fread(buf,l ,2402,fdi); 
nbyte=fwrite(buf,l ,2402,fdo); 

/* read checksum */ 
nbyte=fread(buf, 1 ,4,fdi); 
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I 

fclose (fdi); 
fclose (fdo); 
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APPENDIX D - ROUTINES TO DRAW TERRAIN POLYGONS 



These routines are used to draw the actual polygons. They are independent of the data 
structure used to store the terrain data. 

/ 

* FnName; make_polly.c 

* Author; FRANK HARRIS 

* Purpose: to draw two triangles that are the correct 

orientation and color for the terrain display 

make_poUy(col,i,j,a,b,c,d,level_size) 

short col;/* a flag to indicate what color to draw square */ 
int ij;/* world coord location of lower left point "a" */ 
int a,b,c,d;/* elevation points */ 

int level_size;/* tells what size each side of the polygon is */ 



if(col==l) 

color(GREENl); 

else 

color(GREEN2); 



if((a==0)&&(b==0)&&(c==0)&&(d==0)) 

I 

} 

else if ((a!=0)&&(b==0)&&(c==0)&&(d==0)) 

I 

pmvi(i,a,j); 
pdri(i,b,j-level_size); 
pdri(i+le vel_s ize ,d,j); 
pclosO; 

) 

else if ((a==0)&&(b!=0)&&(c=0)&&(d=0)) 

{ 

pinvi(i,a,j); 

pdri(i,b,j-level_size); 

pdri(i+level_size,c,j-level_size); 

pclosO; 

) 

else if ((a==0)&&(b==0)&&(c!=0)&&(d==0)) 

{ 

pmvi(i,b,j-level_size); 
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pdri(i+level_size,c,j-level_size); 
pdri ( i+le vel_s ize ,d ,j) ; 
pclosO; 

) 

else if ((a==0)&&(b=0)&&(c=0)&&(d!=0)) 

{ 

pmvi(i,a,j); 

pdri(i+level_size,cj-level_size); 

pdri(i+level_size,d,j); 

pclosO: 

} 

else 

{ 

pmvi(i,a,j); 

pdri(i,b,j-level_size); 

pdri(i+level_size,c,j-level_size); 

pclosO; 

pmvi(i,a,j); 

pdii(i+level_size,c,j-level_size); 

pdri(i+level_size,d,j); 

pclosO; 

) 

} 
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FnName: draw_skirt.c 

" Author: FRANK HARRIS 

■*' Purpose: this routine is used to draw a vertical 

plane to be used as a gap filler between 
resolutions 



draw_skirt(x 1 ,z 1 ,y 1 ,x2,z2,y 2,cell_size) 
int xl,zl,yl,x2,z2,y2,cell_size; 

{ 

if((yl!=0)ll(y2!=0)) 

{ 

color(GREENl); 

pmvi(x 1 *cell_size,y 1 ,zl *cell_size); 
pdri(x2*cell_size,y2,z2*cell_size); 
pdri(x2*cell_size,0,z2*cell_size); 
pdri(xl *cell_size,0,zl *cell_size); 
pdosO; 



) 
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APPENDIX E - ROUTINES TO DRAW THE TERRAIN 



These routines calculate the structure independent information required to draw the 
terrain. The main procedure in this section is draw_terrain( ). Tliis proceudure controls 
the drawing process and calls the structure dependent code to actually draw the terrain. 
The second procedure adjust _bounds( ) is called by the structure dependent code to adjust 
the input parameters to match the cell coordinates for the particular cell being drawn. 
#include "terrain.h" 

octant myworld; 

int min4(),max4(),min3()/nax3(); 

* FnName: draw_terrain.c 

* Author: FRANK HARRIS 

* Date: feb 88 

/* 3d terrain display */ 



draw_terrain(view) 
viewpoint view; 

{ 

int ij; 

/* boundray points for three resolutions*/ 

/* farthest points of view triangle for each resolution 
the third vertex is the view position */ 
float level lx 1 devel 1 z 1 .level 1 x 24 evel 1 z2; 
float level2x 1 ,level2z 1 ,level2x2,level2z2; 
float level3x 1 4evel3z 1 ,level3x24evel3z2; 
float angl,ang2,vis; 
float level 14 dir 4 ookx 4 ooky 4 ookz; 
float near, far; 

/* bounding boxes for 3 levels */ 
int max3x,max3z,min3x,min3z; 
int max2x,max2z,min2x,min2z; 
int maxlx,maxlz,minlx,minlz; 
int gridx,gridz; 



/* for timer routines */ 
long ttime.cpu, elapse; 
struct tms ctime; 
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/* number of yards to the horizon */ 
vis = (VIS_COIF*sqrt(view.posy)); 
level 1 = vis/SIN_FOV; 
if (vis > view.max_vis) 
vis = view.max_vis; 



/* compute visability triangle */ 

/♦ triangle has verticies of current position and the line following 
the course out a distance of the computed visibility based on 
the height of eye and the area FOV degrees on either side of 
that line. */ 

angl = view.lookdir - FOV; 
if (angl < 0.0) 
angl = angl + 360.0; 
ang2 = view.lookdir + FOV; 
if (ang2 > 360.0) 
ang2 = ang2 - 360.0; 



/* compute points to draw to for all three levels */ 
level 1x1 = view.posx + (level 1 * sin(DtoR*angl)); 
levellzl = (-view.posz + (levell * cos(DtoR*angl))); 
level 1x2 = view.posx + (levell * sin(DtoR*ang2)); 
level lz2 = (-view.posz + (levell * cos(DtoR*ang2))); 

level2xl = view.posx + (LEVEL2 * sin(DtoR*angl)); 
level2zl = (-view.posz + (LEVEL2 * cos(DtoR*aiigl))); 

Ievel2x2 = view.posx + (LEVEL2 * sin(DtoR*ang2)); 

Ievel2z2 = (-view.posz + (LEVEL2 * cos(DtoR*ang2))); 

level3xl = view.posx + (LEVEL3 * sin(DtoR*angl)); 
level3zl = (-view.posz + (LEVEL3 * cos(DtoR*angl))); 

Ievel3x2 = view.posx + (LEVEL3 * sin(DtoR*ang2)); 

Ievel3z2 = (-view.posz + (LEVEL3 * cos(DtoR*ang2))); 

/* find max and min values for bounding box on all three areas */ 
maxlx = (max3(levellxl,levellx2, view.posx) /CELL_SIZE1); 
maxlz = (max3(levellzl4evellz2, -view.posz)/ CELL_S1ZE1); 
minlx = (min3(level 1x1, level 1x2, view.posx) /CELL_SIZE1 ); 
minlz = (min3 (level lzl,levellz2,- view .posz)/CELL_SIZEl); 

max2x = (max3(level2xl,level2x2,view.posx) / CELL_SIZE2); 
max2z = (max3(level2zl4evel2z2,-view.posz)/ CELL_S1ZE2); 
min2x = (min3(level2xl,level2x2,view.posx) / CELL_SIZE2); 
min2z = (min3(level2zl,level2z2,-view.posz)/ CELL_S1ZE2); 
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max3x — (max3(level3xl,level3x2,view.posx) / CELL_SIZE3); 
max3z = (max3(level3zl,level3z2,-view.posz)/ CELL_SIZE3); 
min3x = (min3(level3xl,level3x2,view.posx) / CELL_SIZE3); 
min3z = (min3(level3zl,level3z2,-view.posz)/ CELL_SIZE3); 






pushmatrixO; 

/* compute vierwpoint for perspective */ 
looky = view .posy - 100.0*(tan(DtoR*view.lookang)); 
lookx = view.posx + 100.0*(sin(DtoR*view.lookdir)); 
lookz = view.posz - 100.0*(cos(DtoR*view.lookdir)); 



far = vis * 1.5; 
near = far/1000.0; 



perspective(FOVY, ASPECT, near, far); 
lookat(view.posx,view.posy,view.posz,lookx4ooky,lookz,0); 

color(SKYBLUE); 

clear(); 



zbuffer(TRUE); 

zclearO; 

/* start the timer */ 
set_timer(&ttime,&ctime); 



/* draw sea to horizon */ 

/* sea drawn 6 yards below horizon to solve z-buffer problem */ 
color(BLUE2); 

pmv(view.posx,-6.0,view.posz); 
pdr(level 1 x 1 ,-6 .0,-level 1 z 1 ); 
pdr(level 1 x2, -6.0,-level 1 z2); 
pclosO; 



/* draw grid lines */ 
if(view.gridlines == TRUE) 



color(WHITE); 
setlinestyle(SOLID); 
linewidth(l); 
if(view.posy > 300) 

{ 

gridx = view.posx/CELL_SIZEl; 
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gridz = view.posz/CELL_SIZEl; 
for (i=0;i<5;i++) 

{ 

movei((gridx+i)*CELL_SIZEl,-2,(gridz+5)*CELL_SIZEl); 

drawi((gridx+i)*CELL_SIZEl,-2,(gridz-5)*CELL_SIZEl); 

movei((gridx-i)*CELL_SIZEl,-2,(gridz+5)*CELL_SIZEl); 

drawi((gridx-i)*CELL_SIZEl,-2,(gridz-5)*CELL_SIZEl); 

) 

for (i=0;i<5;i++) 

{ 

movei((gridx+5)*CELL_SIZEl,-2,(gridz+i)*CELL_SIZEl); 
drawi((gridx-5)*CELL_SIZEl ,-2,(gridz+i)*CELL_SIZEl ); 
movei((gridx+5)*CELL_SIZEl,-2,(gridz-i)*CELL_SIZEl); 
drawi((gridx-5)*CELL_SIZEl,-2,(gridz-i)*CELL_SIZEl); 



if(view.posy > 150) 

I 

gridx = view.posx/CELL_SIZE2; 
gridz = view.posz/CELL_SIZE2; 
setlinestyle(DASHED); 
for (i=0;i<15;i++) 

{ 

movei((gridx+i)*CELL_SIZE2,-2,(gridz+15)*CELL_SIZE2); 

drawi((gridx+i)*CELL_SIZE2,-2,(gridz-15)*CELL_SlZE2); 

movei((gridx-i)*CELL_SIZE2,-2,(gridz+15)*CELL_vSIZE2); 

drawi((gridx-i)*CELL_SIZE2,-2,(gridz-15)*CELL_SIZE2); 

I 

for (i=0;i<15;i++) 

{ 

movei((gridx+15)*CELL_SIZE2,-2,(gridz+i)*CELL_SIZE2); 

drawi((gridx-15)*CELL_SIZE2.-2,(gridz+i)*CELL_SIZE2); 

movei((gridx+15)*CELL_SIZE2,-2.(gridz-i)*CELL_SIZE2); 

drawi((gridx-15)*CELL_SIZE2,-2,(gridz-i)*CELL_SIZE2); 

) 



if(view.posy < 200) 

{ 

gridx = view.posx/CELL_SIZE3; 
gridz = view.posz/CELL_SIZE3; 
setlinestyle(DOTTED); 
for (i=0;i<30;i++) 

I 

movei((gridx+i)*CELL_SIZE3,-2,(gridz+30)*CELL_SIZE3); 
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drawi((gridx+i)*CELL_SIZE3,-2,(gridz-30)*CELL_SIZE3); 

movei((gridx-i)*CELL_SIZE3,-2,(gridz+30)*CELL_SIZE3); 

drawi((gridx-i)*CELL_SIZE3,-2,(gridz-30)*CELL_SIZE3); 

) 

for (i=0;i<30;i++) 



movei((gridx+30)*CELL_SIZE3,-2,(gridz+i)*CELL_SIZE3); 

drawi((gridx-30)*CELL_SIZE3,-2,(gridz+i)*CELL_SIZE3); 

movei((gridx+30)*CELL_SIZE3,-2,(gridz-i)*CELL_SIZE3); 

drawi((gridx-30)*CELL_SIZE3,-2,(gridz-i)*CELL_SIZE3); 

) 



} 

) 

/* draw any terrain */ 

I* always draw the cell your in */ 

draw_cell(CELL ,vie w .lat ,vie w .longg ,max 1 x 4 iiin 1 x ,max 1 z ^tiin 1 z, 
max2x,min2x,max2z,min2z, 
max3x ^iin3x,max3z4Tun3z); 



if ((maxlx > 10)&&(minlx < 0)&&(maxlz >10)) 

( 

draw_cell(ABOVE,view.lat+l,view.longg,maxlx,minlx 4 naxlz,minlz, 

max2x,min2x,max2z,min2z, 

rnax3x,rriin3x,rnax3z,i'nin3z); 

draw_cell(RTUP,view.lat+l,view.longg+l 4 naxlx 4 Tiinlx,maxlz,niinlz, 
max2x,min2x,max2z,min2z, 
max3x 4Tiin3x,max3z^Tiin3z); 

draw_cell(LTUP,view.lat+l,view.longg-l 4 naxlx 4 ninlx,niaxlz,minlz, 
max 2x ,min2x ,max2z,min2z, 
max3x,min3x,max3z4Tiin3z); 

) 

else if ((maxlx > 10)&&(minlx < 0)&&(ininlz <0)) 

I 

draw_cell(B ELO W, view . lat- 1 ,view .longg ,max 1 x ,min 1 x ,max 1 z,min 1 z, 
max2x,min2x,max2z,min2z, 
max3x ^Tun3x,max3z4Tiin3z); 

draw_cell(RTDN ,view .lat- 1 ,view .longg+ 1 4 Tiax 1 X ^nin 1 X ,max 1 z,min 1 z, 
max 2x ,min2x ,max2z,min2z, 
max3x 4Tiin3x ,max3 z ^Tiin3 z) ; 

draw_cell(LTDN,view.lat-l,view.longg-l, maxlx, minlx,maxlz,minlz, 
max2x,min2x,max2z,min2z, 
max3x 4Tiin3x ,max3 z 4Tiin3z) ; 

) 

else if ((maxlz > 10)&&(minlz < 0)&&(maxlx >10)) 
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draw_cell(RlG HT, vie w.lat, view. longg+ 1 ^nax lx, min lx, max 1 z,minl z, 
max2x,min2x,max2z,min2z, 
max3x,min3x,max3z,min3z); 

dra w_ceU(RTDN, view .lat- 1 , view .longg+ 1 4 Tiax 1 x^nin 1 X, max 1 z,minl z, 
max2x,min2x,max2z,min2z, 
max3x 4nin3x,max3z,min3z); 

draw_ceU(RTUP,view ,lat+ 1 ,view.longg+ 1 ,max 1 x ^nin 1 x,max 1 z,minl z, 
max2x ,min2x ,max2z,min2z, 
max3x,min3x,max3z4Tiin3z); 

) 

else if ((maxlz > 10)&&(minlz < 0)&&(minlx <0)) 

{ 

draw_ceU(LEFT,view.lat,view .longg- 1 ,max 1 x ,min lx ^nax 1 z,min 1 z, 
max2x ,min2x ,max2z,min2z, 
max3x,min3x,max3z,min3z); 

draw_ceU(LTUP,view.lat+l,view.longg-l,maxlx,minlx,maxlz,minlz, 
max2x,min2x ,max2z,min2z, 
max3x4Tiin3x,max3z,min3z); 

draw_ceU(LTDN,view.lat- 1 ,view.longg- 1 ,max lx,min lx ,max lz,minlz, 
max2x,min2x,max2z,min2z, 
max3x,min3x,max3z,min3z); 

) 

else if ((max lx > 10)&&(maxlz > 10)) 

( 

draw_cell(ABOVE,view.lat+l,view.longg,maxlx,minlx,maxlz,minlz, 

max2x,min2x,max2z,min2z, 

max3x,min3x,max3z,min3z); 

draw_ceU(RTUP,view.lat+l,view.longg+l,maxlx 4 'ninlx,maxlz,minlz, 
max2x ,min2x ,max2z,min2z, 
max3x,min3x,max3z,min3z); 

draw_cell(RIGHT,view.lat,view.longg+ 1 4 nax 1 x,min lx,max 1 z,min 1 z, 
max2x,min2x,max2z,min2z, 
max3x4nin3x,max3z,min3z); 



else if ((max lx > 10)&&(minlz < 0)) 

{ 

draw_cell(BELOW,view.lat-l,view.longg,maxlx,minlx,maxlz,minlz, 

max2x,min2x,max2z,min2z, 

max3x,min3x,max3z,min3z); 

draw_cell(RTDN,view.lat- 1 ,view.longg+ 1 ,max 1 x ,min 1 x,max 1 z,min 1 z, 
max2x,mm2x,max2z,min2z, 
max3x4nm3x,max3z4nin3z); 

draw_cell(RIGHT,view.lat,view.longg+ 1 4 Tiax lx,minl x,max lz,minlz. 
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I 



max2x ,min2x ,max2z,min2z, 
max3x,min3x,max3z4Tiin3z); 



else if ((minlx < 0)&&(minlz < 0)) 

I 

draw_cell(BELOW,view.lat- 1 ,view.longg,max lx,min lx,max lz,min Iz, 
max2x,min2x,rnax2z,min2z, 
max3x,min3x,max3z4Tiin3z); 

draw_cell(LTDN , view. lat- 1 ,view.longg- 1 4 Tiax 1 X, min 1 X, max 1 z, min 1 z, 
max2x,min2x,max2z,min2z, 
max3x4Tiin3x,max3z,min3z); 

draw_cell(LEFT,view.lat,view.longg-l,maxlx,minlx,maxlz,minlz, 

max2x,min2x,max2z,min2z, 

max3x4nin3x,max3z4iiin3z); 



I 

else if ((minlx < 0)&&(maxlz >10)) 

I 

draw_ceU( AB O VE.view .lat+ 1 ,view .longg ,max 1 x ,min 1 x ^nax 1 z ,min 1 z, 
max2x,min2x,max2z,min2z, 
max3x,min3x,max3z,min3z); 

draw_cell(LTUP,view.lat+ 1 .view. longg- 1 .max 1 x^nin 1 x.max 1 z.min 1 z. 
max2x .min2x .max2z .min2z. 
max3x .min3x .max3z .min3z); 

draw_cell(LEFT.view.lat.view.longg-l.maxlx.minlx 4 naxlz.minlz. 
m ax2x .min2x .max2z.min2z. 
max3x4nin3x.max3z4nin3z); 



I 

else if ((maxlx > 10)) 

I 

draw_cell(RIGHT.view.lat.view.longg+l.maxlx 4 ninlx.maxlz.minlz. 
max2x.min2x.max2z,min2z. 
max3x 4nin3x .max3z 4nin3z); 



I 

else if ((minlx < 0)) 

I 

draw_cell(LEFT .view. lat. view .longg- 1 .max lx. min 1 X. max 1 z.min 1 z. 
max2x.min2x.max2z.min2z. 
max3x4nin3x.max3z.min3z); 



else if ((maxlz > 10)) 
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t 

( 

draw_cell( ABO VE,view.lat+ 1 ,view.longg,max 1 x^ninl x^nax 1 z,minlz, 
max2x,min2x,inax2z,min2z, 
max3x,min3x,max3z4Tiin3z); 



) 

else if ((minlz < 0)) 

{ 

draw_cell(B ELO W.view.lat- 1 ,view.longg ,max 1 x,inin 1 x, max 1 z,min 1 z, 
max2x ,min2x ,max2z,min2z, 
max3x4nin3x,max3z,min3z); 



} 



zbuffer(FALSE); 



popmatrixO; 

elapse = read_timer(&ttime,&ctutie,&cpu); 

printf(" time: elapse %d epu %d", elapse, qju); 
) 
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adjust_bounds(size,cell,maxx4Tiinx,maxz,minz) 
int size,ceU,*maxx,*maxz,*minx,*minz; 

I 

if(*maxx>size) 

if((ceU==RIGHT)ll(ceU==RTUP)ll(ceU=RTDN)) 



*maxx = *maxx - size; 
*miiix = 0; 



else 

I 

*maxx = size; 

) 

else 

if ((cell==RIGHT)ll(ceU==RTUP)ll(celI==RTDN)) 

{ 

*maxx = 0; 

*minx = 0; 

) 

if(*maxz>size) 

if((ceU==ABOVE)ll(ceU==RTUP)ll(ceU=LTUP)) 

I 

*maxz = *maxz - size; 

*minz = 0; 

) 

else 

I 

*maxz = size; 

) 

else 

if((ceU==ABOVE)ll(cell=RTUP)ll(ceU=LTUP)) 

I 

*maxz = 0; 

*minz = 0; 

) 

if(*minx<0) 

if((ceU=LEFT)ll(ceU=LTUP)ll(ceU=LTDN)) 

I 

*minx = *minx + size; 

*maxx = size; 

) 

else 
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*miiix = 0; 

} 

else 

if((cen==LEFT)ll(cell==LTUP)ll(cell=LTDN)) 

{ 

*maxx = 0; 

*mlax = 0; 

) 

if(*minz<0) 

if ((cell=BELOW)ll(cell==RTDN)ll(cell==LTDN)) 

{ 

*minz = *minz + size; 

*maxz = size; 

} 

else 

I 

*minz = 0; 

) 

else 

if((cell==BELOW)ll(cell==RTDN)il(cell==LTDN)) 

{ 

*maxz = 0; 

*minz = 0; 

) 

) 
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APPENDIX F - MULTIPLE ARRAY DATA STRUCTURE 



Tliese are the structure dependent routines used with the multiple array data 
structure discussed in Chapter five. The procedure 3a.c is used to preprocess the DMA 
digital terrain elevation data and place the processed data in a file format that is easily 
read by the application program. TTie terrain data is initially read into the application 
program’s structure by the procedure getjerrain(). The final structure dependent 
procedure is draw_cell(). It is used to actually access the data structure and draw the 
visible terrain. 

* FnName: 3a.c 

* Author: FRANK HARRIS 

* Date: mar 88 

* Purpose: make 3 tier data stmcture file 

for display terrain. 

uses structure of three seperate 

arrays. 

**************************** *1 

#include <stdio.h> 

#include <string.h> 

#include <sys/types.h> 

#define maxelev 10000/* in yards higher the eve rest */ 

#define FALSE 0 
#defineTRUE 1 
#define buf_size 28672 
char *BUF ,*BUFO; 
char *malloc(); 
short level3[1201][1201]; 
short level2[101][101]; 
short levell[ll][ll]; 

main(argc,argv) 
int argc; 
char *argvG; 

{ 

int row,j,i,s,t,n,sub,nbyte; 
char *name; 
char c[2]; 
short *P,lat,log; 

HLE *fdi,*fdo; 

/* open input file */ 
if((fdi=fopen(argv[l],"r")) < 0) 

{ 
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printfC'cannot open fileO); 
exitO; 



I* set up input buffer */ 

if ((BUF=malloc((buf_size )+!)) == NULL) 

{ 

fprintf(stderr,"out of memoryO); 
exit(l); 

} 

setvbuf(fdi,BUF,_IOFBF,t>uf_size ); 

/* read 1 colume of data at a time and put in an array 
the first index is the colume number "longitude" 
the second is for the row or latitude 
index [0][0] is the lower left comer of tlie cell*/ 
for (i=0;i<=1200;i++) 

I 

P = &level3[i][0]; 
nbyte = fread(P,2,1201,fdi); 

} 

/* close input file no longer needed */ 

free(BUF); 

fclose(fdi); 

/* make output file name */ 
name = argv[l]; 
strcat(name,".3a"); 

/* open output file */ 
if((fdo=fopen(name,"w")) < 0) 

{ 

printfC'cannot open output fileO); 
exitO; 

) 

/* setup output buffer */ 

if ((BUFO=malloc((buf_size )+!)) == NULL) 

{ 

fprintf(stderr," out of memoiy"); 
exit(l); 

} 

setvbuf(fdo,BUFO,_IOraF,buf_size ); 
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/* convert lat long in file name to short int values */ 
if (name_conv(&lat,&log,argv[l])) 

I 

printf(" filename not propper LAT/LONG"); 
exit(l); 

) 



/* start the file with lat long of lower left comer */ 
nbyte=fwrite(&lat,2,l ,fdo); 
nbyte=fwrite(&log,2,l ,fdo); 



for (i=0;i<=100;i++) 
for (j=0;j<=100;j++) 

I 

/* cell boundary */ 
if((i=0)ll(j==0)ll(i=100)ll(j=100)) 
level2[i] U]=level3 [i* 1 2] |j* 1 2] ; 
else 

I 

sub=0; 

for(s=((i-l)*12);s<((i+l)*12);s++) 

for(t=((j-l)*12);t<((j+l)*12);t++) 

{ 

sub = sub + levels [s][t]; 

) 

level2[i][J] = sub/576; 

) 

) 

for (i=0;i<=10;i++) 
for (j=0;j<=10;j++) 

{ 

/* cell boundary */ 
if((i=0)ll(j==0)ll(i=10)ll(j=10)) 
level 1 [i] U]=level2[i* 1 0] |j* 1 0] ; 
else 

I 

sub=0; 

for(s=((i-l)*10);s<((i+l)*10);s++) 
for(t=((j- 1 )* 10);t<((j+ 1 )* 1 0);t++) 
{ 

sub = sub + level2[s][t]; 

} 

levell[i]|j] = sub/400; 
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I 

I 

/* write out the arrays */ 
for (i=0;i<=1200;i++) 

{ 

P = «&level3[i][0]; 

nbyte = fwrite(P,2,1201,fdo); 

) 

for (i=0;i<=100;i++) 

{ 

P = &level2[i][0]; 
nbyte = fwrite(P,2,101,fdo); 

) 

for (i=0;i<=10;i++) 

{ 

P = &levell[i][0]; 
nbyte = fwrite(P,2,ll,fdo); 

} 

/* clean up */ 
fclose (fdo); 
free(BUFO); 



int name_conv(lat, log, name) 
short *lat,*log; 
char *'name; 

{ 

short temp; 

/* assume all lats and longs are north and east respectively */ 

temp~(short )name [0] -48 ; 
if ((tcmp<0)ll(temp>9)) 
retum(-l); 

*lat — temp * 10; 
temp~(short )name [ 1 ] -48 ; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*lat = *lat -4- temp; 



temp=( short )name[3 ] -48 ; 
if ((temp<0)ll(temp>9» 
retnm(-l); 

*log - temp * 100; 
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temp=(short)name[4]-48; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*log = ((temp* 10) + *log); 
temp=(short )name [5 ] -48 ; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*log = (temp + *log); 
retum(O); 



#include <string.h> 
#include <sys4>aram.h> 
#include <sys/types.h> 
#include <sys/times.h> 
#include "gl.h" 

#include "device.h" 
#mclude "constants .h" 
#include "typedef.h" 
#include "stdio.h" 



#define maxelev 10000/* in yards higher the everest */ 
#define buf_size 28672/* for input buffer */ 

char *malloc(); 
char *BUF; 

octant myworld; 

* FnName: get_terrain.c 

* Author: FRANK HARRIS 

* Date: feb 88 

* Amended: 

* Purpose: 

* Params: 

* Returns: 

get_terrain(lat,longg) 
short lat,longg; 

{ 

int row,j,i,n,nbyte; 

char name[10],filenaine[100]; 

short buf[512]; 

FILE *fdi; 
cellptr ptr; 
cell P; 

short *ptrl,*ptr2,*ptr3; 

name_conv(lat,longg.name); 

strcpy(filenaTie,'7usr/work/fhaiTis/3t_work/"); 

strcat(filenarne,name); 

strcat(filename,".3a"); 

/* open input file */ 
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if((fdi=fopen(filename,"r")) < 0) 

I 

fprintf(stdeiT, "cannot open fileO); 

) 

else 

{ 

/* set up input buffer */ 
if ((BUF=malloc((buf_size )+!)) = NULL) 
{ 

fprintf(stderr,"out of memoryO); 

) 

else 

{ 

setvbuf(fdi,BUF,_IOFBF,buf_size ); 



/* get lat long first 2 items in file */ 
fread(buf,2,2,fdi); 

/* make structure put pointer in world structure */ 
myworld[lat]Pongg-90] = (cellptr)malloc(sizeof(cell)); 

/* read in the arrays */ 
ptr= myworld[lat]Pongg-90]; 
for (i=0;i<=1200;i++) 

{ 

ptr3 = &(ptr->level3[i][0]); 
nbyte = fread(ptr3,2,1201,fdi); 



for (i=0;i<=100;i++) 

{ 

ptr2 = &(ptr->level2[i][0]); 
nbyte = fread(ptr2,2,l01,fdi); 

) 

for (i=0;i<=l0;i++) 

{ 

ptrl = &(ptr->levell[i][0]); 
nbyte = fread(ptrl,2,ll,fdi); 



/* clean up */ 
fclose (fdi); 
free(BUF); 

) 

) 
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/* pass in lat/long will return filename */ 



name_conv(lat,longg,name) 
short lat,longg; 
char name[10]; 

I 

I* assume all lats and longs are north and east respectively */ 
char c[2]; 



c[l]= ’ 
name[l]=’ 

name[0] = (char)((lat/10)+48); 

c[0] = (char)((lat%10)+48); 

strcat(name,c); 

c[0] = ’N’; 

strcat(name,c): 

c[0] = (char)((longg/100)+48); 

strcat(name,c); 

longg=longg% 1 00; 

c[0J = (char)((longg/l0)+48); 

strcat(name,c); 

c[0] = (char)((longg%10)+48); 

strcat(name,c); 

dO] = ’E’; 

strcat(name,c); 

) 
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^* **************************** 

* FnName: Draw_cell 

* Author; FRANK HARRIS 

* Purpose: Draws on e cell of terrain based on the 

input parameters.s version uses the 
multiple array data stmcture 

draw_cell(cel ,lat ,longg .maxlx.minlx^naxl z,min 1 z, 
max 2 x,min 2 x 4 nax 2 z,min 2 z, 
max3x,min3x^ax3z,min3z) 
short cel,lat,longg; 
int niaxlx,minlx,maxlz,minlz; 
int max2x,min2x,max2z,min2z; 
int max3x,min3x,max3z,min3z; 

{ 

int maxsub2x,maxsub2z,minsub2x,minsub2z;/* overlap bounds */ 

int maxsub3x,maxsub3z,minsub3x,minsub3z; 

int stxl,stzl,spxl,spzl;/* start stop points for dif resolutions */ 

int stx2,stz2,spx2,spz2; 

int stx3,stz3,spx3,spz3; 

int i,j,s,t,u,v; 

ceUptr ptr; 

/* get cell record */ 

if ((ptr = myworld[lat][longg-90]) == NULL) 

{ 

get_terrain(lat,longg); 

ptr = myworld[lat][longg-90]; 

) 

if(ptr!=NULL) 

{ 

/* adjust bounds dep>ending on what cell were drawing */ 
adJust_bounds( 10,cel,&max lx,&minl x,&max 1 z,&min Iz); 
adjust_bounds( 100,cel ,&max2x,&min2x,&max2z,&min2z); 
adjust_bounds( 1200, cel, «&max3x,&min3x,«&max3z,&min3z); 

/* calculate overlap boundaries */ 

maxsub2x = (max2x/10);/*Ievel2 boundary with level 1*/ 
maxsub2z = (max2z/10); 
minsub2x = (min2x/10); 
minsub2z = (min2z/10); 

maxsub3x = (max3x/12);/*level3 boundary with level2.*/ 
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maxsubSz = (max3z/12); 
minsubSx = (min3x/12); 
minsub3z = (inin3z/12); 

/* adjust so will draw correctly when looking south and west */ 

/* stops the loop from accessing out of the array */ 
if(maxlx=10) 
maxlx = 9; 
if(maxlz=10) 
maxlz = 9; 

/* draw level 1 area with all three resolutions */ 
for(i=min 1 x;i<=max 1 x ;i++) 
for(j=niin 1 z;j<=max 1 z;j++) 

( 

if( ! ((i>=minsub2x)&&(i<maxsub2x)&&(j>=minsub2z)&&(j<maxsub2z))) 
/* draw level 1 square */ 

{ 

inake_poUy((i+j)%2,(i*CELL_SIZEl ),-(j*CELL_SIZEl ), 
ptr->le vel 1 [i] [j] ,ptr->level 1 [i] [J+ 1 ] , 
ptr->level 1 [i+ 1 ] [j+ 1 ] ,ptr->level 1 [i+ 1 ] [j] , 

CELL_SIZE1); 

I 

)/* level 1 area */ 

/* draw Ievel2 area */ 

for(s=(minsub2x* 1 0); s<(maxsub2x * 1 0);s++) 
for(t=(minsub2z* 1 0);t<(maxsub2z* J 0);t++) 

I 

if(!((s>=minsub3x)&&(s<maxsub3x)&& 

(t>=minsub3z)&&(t<maxsub3z))) 

{ 

make43olly( (s+t)%2,(s*CELL_SIZE2), -(t*CELL_SIZE2), 
ptr->level2[s] [t] ,ptr->level2[s] lt+ 1 ] , 
ptr->le vel2[s+ 1 ][t+ 1 ] ,ptr->le vel2[s+ 1 ] [t] , 

CELL_SIZE2); 

/* to cover up diffrences in resolution boundaries 
don’t need between level 1 and 2 too far to be noticeable */ 
if((s=minsub3x)ll(s==maxsub3x)) 

{ 

draw_skut(s,-t ,ptr->le vel2 [s ] f t] , 
s,-(t+ 1 ),ptr->level2[s] [t+ 1 ] , 

CELL_SIZE2); 

} 
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if((t=ininsub3z)ll(t==maxsub3z)) 

{ 

draw_skirt(s,-t,ptr->level2[s][t], 

(s+l),-t,ptr->level2[s+l][t], 

CELL_SIZE2); 

) 

} 

}/* level 2 area */ 

/* draw level3 area */ 

for(u=(minsub3x*12);u<(maxsub3x*12);u-H-) 
for(v=(minsub3z* 1 2);v<(maxsub3z* 1 2);v++) 

{ 

make_polly( (u+v)%2,(u*CELL_SIZE3), -(v*CELL_SIZE3), 
ptr->level 3 [u] [v J ,ptr->le vel3 [u] [ v+ 1 ] , 
ptr->level3 [u+ 1 ] [v+ 1 ] ,ptr->level3 [u+ 1 ] [v] , 
CELL_SIZE3); 

)/* level 3 area */ 

}/* if cell has value */ 

} 
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APPENDIX G - HBERARCICAL DATA STRUCTURE WITH POINTERS 



These are the structure dependent routines used with the multiple array data 
structure discussed in Chapter five. The procedure 3t.c is used to preprocess the DMA 
digital terrain elevation data and place the processed data in a file format that is easily 
read by the application program. The terrain data is initially read into the application 
program’s structure by the procedure getjerrain(). The final structure dependent 
procedure is draw_cell(). It is used to actually access the data structure and draw the 
visible terrain. 

* FnName: 3t.c 

Author: FRANK HARRIS 

* Date: mar 88 

* Purpose: make 3 tier data structure file for 

display terrain. Uses a hierarchical structure 
with pointers to store the terrain. 

#include <stdio.h> 

#include <string.h> 

#include <sys/types.h> 

#define maxelev 10000/* in yards higher the everest */ 

#define FALSE 0 
#define TRUE 1 
#define buf_size 28672 
char *BUF,*BUFO; 
char *malloc(); 
short terrain[1201][1201]; 

typedef struct { 

short data[13][13]; 

) level3_rec; 

typedef level3_rec *ptr3; 

typedef struct | 

ptr3 level3ptr[ll][ll]; 

short level3val[ll][ll]; 

short all_zero; 

}level2_rec; 

typedef level2_rec *ptr2; 

typedef struct! 

ptr2 level2ptr[ll][llj; 

short level2val[ll][ll]; 
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short all_zero; 
)levell_rec; 

typedef level l_rec *ptrl ; 

typedef ptrl octant[90][90]; 
octant myworld; 
ptrl do_levell(); 
ptr2 do_level2(); 
ptr3 do_level3(); 

main(argc,argv) 
int argc; 
char *argv[]; 

I 

int row,j,i,n,nbyte; 
char *name; 
char c[2]; 
short *P,lat,log; 

FILE *fdi,*fdo; 

/* open input file */ 
if((fdi=fopen(argv[l],"r”)) < 0) 

I 

printf("cannot open fileO); 
exitO; 



/* set up input buffer */ 

if ((BUF=maUoc((buf_size )+l)) = NULL) 

I 

fprintf(stderr,"out of memoryO); 
exit(l); 

) 

setvbuf(fdi,BUF,_IOFBF,buf_size ); 

/* read 1 colume of data at a time and put in an array 
the first index is the colume number "longitude" 
the second is for the row or latitude 
index [0][0] is the lower left comer of the cell*/ 
for (i=0;i<=1200;i++) 

I 

P = «feterrain[i][0]; 
nbyte = fread(P,2,1201,fdi); 

) 

/* close input file no longer needed */ 
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free(BUF): 

fclose(fdi); 

/* make output file name */ 
name = argv[l]; 
strcat(name,".3t"); 

/* open output file */ 
if((fdo=fopen(name,"w")) < 0) 

( 

printf("cannot open output fileO); 
exitO; 

j 



/* setup output buffer */ 

if ((BUFO=maUoc((buf_size )+!)) == NULL) 

{ 

fprintf(stderr," out of memory"); 
exit(l); 

) 

setvbuf(fdo,BUFO,_IOFBF,buf _size ); 

/* convert lat long in file name to short int values */ 
if (name_conv(«felat,&Iog,argv[l])) 

{ 

printfC filename not propper LAT/LONG"); 
exit(l); 

) 



/* start the file with lat long of lower left comer */ 
nbyte=fwrite(&lat,2, 1 ,fdo); 
nbyte=fwrite(&log,2, 1 ,fdo); 

/* make structure put pointer in world structure */ 
my worldDat] [log-90] = do_levell(); 

/* put overlap data in each cell */ 

insert_overlap(myworld[lat][log-90]); 
out_terrain(myworld[lat] [log-90] ) ; 

/* v/riteout the stmcture to reuseable file */ 
writeit(fdo4nyworld[lat][log-90]); 

/* clean up */ 
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fclose (fdo); 
free(BUFO); 



^3|< 3|< 3j< ★ Jk ★ Jk* Jk 3|<3|< 3|<3|<*3|<3k *★★*★**★♦★★ 3k** *3|< 3|<y 



out_terrain(pt) 
ptrl pt; 

{ 

int s,t,i,j; 
ptr2 pt2; 

printf(" levell "); 
foi'(i=10;i>=0;i— ) 

I 

printfC "); 
for(j=0;j<ll;j++) 

{ 

priiitf("%5d ",pt->level2val(j][i]); 

) 

) 

priiuff •'); 
for (i=0;i<l l;i++) 
for(j=0;j<ll;j++) 

{ 

pt2 = pt->level2ptr[i][j]; 
if(pt2 ==NULL) 

printfC null level2 i %d j %d 
else 
{ 

printf(" level2 i %d j %d 
for(s=10;s>=0;s--) 

{ 

printfC "); 
for(t=0;t<ll;t++) 

I 

printf("%5d ”,pt2->level3val[t][s]); 

) 

printfC "); 



) 



^ok* ************************** ****************3k3k:k* 



:k***********y 



insert_overlap(ptr) 
ptrl ptr; 

I 
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if(pti !=NULL) 

! 

Lnt 

ptr2 12,top2,rt2; 

ptr3 I3,top3,rt3; 

/* put in overlap for lev ell*/ 
for (j=0;j<10;j++) 

ptr->level2val[10]|j] = terrain [ 1 200] |j* 120]; 
for(i=0;i<l l;i++) 

ptr->level2val[i][10] = terrain[i* 120] [1200]; 
ptr->level2val[10][10] = terrain [1200] [1200]; 



/* overlap for level2 */ 
for (i=0;i<10;i++) 
for(j=0;j<10;j++) 

{ 

12 = ptr->level2ptr[i][j]; 
if (12 != NULL) 

{ 

top2 = ptr->level2ptr[i][j+l]; 
if(top2 !=NULL) 
for (s=0;s<10;s++) 

12->level3val[s][10] = top2->level3val[s][0]; 
else 

for (s=0;s<10;s++) 

12->level3val[s][10] = 0; 
rt2 = ptr->level2ptr[i+l][j]; 
if (rt2 != NULL) 
for (s=0;s<10;s++) 

12->level3val[10][s] = rt2->level3val[0][s]; 
else 

for (s=0;s<10;s++) 

12->level3val[s][10] = 0; 
rt2 = ptr->level2ptr[i+l][j+l]; 
if (rt2 != NULL) 

12->level3val[10][10] =-- rt2->level3val[0][0]; 
else 

12->level3val[10][10] = 0; 

) 

} 

for (i=0;i<9;i++) 
t 

12 - ptr->level2ptr[i][9]; 
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if (12 !=NULL) 

{ 

for (j=0;j<10;j++) 

I 

/* for outside border */ 

12->level3val(j][10] = terrain[i*120+j*12][1200]; 

/* for right side with adjacent subcell */ 
rt2 = ptr->level2ptr[i+l][9]; 
if(rt2 !=NULL) 

12->level3val[10][j] = rt2->level3val[0]lj]; 
else 

12->level3val[10]|j] = 0; 

) 

12->level3val[10][10] = terrain [i* 120+ 120] [1200]; 

I 

12 = ptr->level2ptr[9][i]; 
if (12 != NULL) 
for (j=0;j<10;j++) 

I 

/* for outside border */ 

12->level3val[10](j] = terrain [ 1 200] [i*120+j* 12]; 

/* for top side with adjacent subcell */ 
rt2 = ptr->level2ptr[9][i+l]; 
if(it2 != NULL) 

12->level3val(j][10] = rt2->level3val[j][0]; 
else 

12->leveBval[j][10] = 0; 

} 

) 

12 = ptr->level2ptr[9][9]; 
if (12 != NULL) 

12->level3val[10][10] = terrain[ 1200] [1200]; 

) 



^3|( 3|c ak 3k 3|c ak 3|c 3k 3|( 3k 3k 3k 3k 3k ak 3|c ak 3k 3k 3k 3k ^ 3k 3k 3k 3k 3k % 3k 3k * 9k 3(c 



writeit(fdo 4 1 ptr) 
FILE *fdo; 
ptrl llptr; 

{ 

ptr2 12ptr; 
ptr3 13 ptr; 
short allzero, edge; 
short value; 
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kit i,j,s,t,u,v; 
allzero = -1; 
edge = -2; 

if (llptr->all_zero) /* entire cell is 0 all ocean */ 

I 

fwrite(&allzero,2,l,fdo);/* write a -1 for allzeros */ 

I 

else /* need to check ceU */ 

{ 

value = 1;/* 1 means data -1 means allzero */ 
fwrite(&value,2,l ,fdo); 
for (i=0;i<l l;i++)/* loop through level 1 */ 
for (j=0;j<ll;j++) 

( 

12ptr = llptr->level2ptr[i][j]; 
if((i==10)ll(j==10)) 

I 

printf(" 1 edge i %dj %d ",i,j); 
fwrite(&edge,2,l,fdo); 
fwrite(&(llptr->level2val[i][j]),2,l,fdo); 

) 

else if(12ptr==NULL)/* subcell is empty, all zeros */ 

I 

fwrite(&ailzero,2,l ,fdo); 

I 

else/* subcell has value, not all zeros */ 

{ 

fwrite(&(llptr->level2val[i][j]),2,l,fdo); 
for(s=0;s<l l;s++)/* loop through level2 */ 
for(t=0;t<l l;t++) 

{ 

13ptr = 12ptr->level3ptr[s][t]; 
if((s=10)ll(t==10)) 

I 

printf(" 2 edge i %d j %d s %d t %d ",i J,s,t); 
fwrite(&edge,2,l,fdo); 
fwrite(&(12ptr->level3val[s][t]),2,l,fdo); 

) 

else if(13ptr==NULL)/* subsubcell is empty, all zeros */ 

{ 

fwrite(&allzero,2,l ,fdo); 

) 

else/* subsubcell has value, not all zeros */ 
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fwrite(&(12ptr->level3val[s][t]),2,l,fdo); 

I 

fwrite(13ptr->data,2, 1 69,fdo); 

) 



) 



) 



) 



) 



y ^ % s|< % % % % % % % % % % % ^ % % 3|( % 3|< 3(c ^ 3(c 

ptrl do_levell() 

I 

ptrl level; 
ptr2 ptr; 
int i,j; 
short allzero; 

/* allocate structure */ 

level = (ptrl)malloc(sizeof(levell_rec)); 

/* make the formattred output file */ 

/* loop through the level 2 data */ 
for(i=0;i<10;i-H-) 
for(j=0;j<10;j++) 

{ 

ptr = do_level2(i,j,&(level->level2val[i](j])); 
if(ptr != NULL) 
allzero = FALSE; 
level->level2ptr[i] [j]=ptr; 



level->aU_zero = aUzero; 
retum(level); 

) 

3fc 9(C ]((:(< 9(C SfofC 3f< ^ 3f( 3fc 4c 3(C ](( 3fc ^ 3(C 3f< 3(< 

ptr2 do_level2(i,j, value) 
int i,j; 
short *value; 

I 

ptr2 level; 
ptr3 ptr; 
int s,t; 
short min; 
short allzero; 
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/* allocate structure */ 

/* allocate level2 data record */ 
inin = maxelev; 

level = (ptr2)malloc(sizeof(level2_rec)); 
allzero =TRUE; 

/* loop through getting level 3 data */ 
for(s=0;s<10;s++) 
for(t=0;t<10;t++) 

I 

ptr = do_level3(i,j,s,t,&(level->level3val[s][t])); 
if(ptr != NULL) 

allzero = FALSE; 
level ->level3ptr[s] [t]=ptr; 
if (level->level3val[s][t] < min) 
mm = level->level3val[s][t]; 

I 

if (allzero) 

{ 

/* all zero don’t need the data */ 

*value = 0; 
free(level); 
retum(NULL); 

I 

else 

I 

/* pass back pointer to the record and min value of area */ 
level->all_zero = allzero; 

*value = min; 
retum(level); 

) 

I 

ptr3 do_level3(i,j,s,t, value) 
int i,j,s,t; 
short *value; 

( 

int u,v; 

level3_rec *level; 
short min,temp, allzero; 

min = maxelev; 

/* get data record for 3rd level */ 
level = (ptr3)malloc(sizeof(level3_rec)); 
allzero = TRUE;/* initialize */ 

/* loop through terrain */ 
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for (u=0;u<13;u++) 
for (v=0;v<13;v++) 

{ 

temp = terrain[i*120+s*12+u]U*120+t*12+v]; 
level->data[uj[v]= temp; 
if (temp!=0) 
allzero = FALSE; 
if (temp<min) 
min = temp; 

) 

if (allzero) 

{ 

/* all zero don’t need to keep the points around */ 

*value = 0; 
free(level); 
retum(NULL); 

} 

else 

/* return the pointer to the record and the min value of the points */ 

I 

*value = min; 
retum(level); 

) 

) 






int name_conv(lat,log^ame) 
short *lat,*log; 
char *name; 

I 

short temp; 

/* assume aU lats and longs are north and east respectively */ 



temp=( short )name[0]-48; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*lat = temp * 10; 
temp=(short )name [ 1 ] -48 ; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*lat = *lat + temp; 



temp=(short)name[3]-48; 
if ((temp<0)ll(temp>9)) 
retum(-l); 
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*log = temp * 100; 
temp=(short )name [4] -48 ; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*log = ((temp* 10) + *log); 
temp=(short)name[5]-48; 
if ((temp<0)ll(temp>9)) 
retum(-l); 

*log = (temp + *log); 
retum(O); 

) 



134 



#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 



<string.h> 

<sys/^aram.h> 

<sys/types.h> 

<sy s/times. h> 

"gl.h" 

"device.h" 

"constants.h" 

"typedef.h" 

"stdio.h" 



#define maxelev 10000/* in yards higher the everest */ 
#define buf_size 28672/* for input buffer */ 

char *malloc(); 
char *BUF; 

extern octant myworld; 
ptrl make_levell(); 
ptr2 make_level2(); 
ptr3 make_level3(); 

* FnName: get_terrain.c 

* Author: FRANK HARRIS 

* Date: feb 88 

get_terrain(lat,longg) 
short latdongg; 

( 

int row,j,i.n,nbyte; 

char name[10],filename[100]; 

short *P,buf[512]; 

FILE *fdi; 



name_conv(lat,longg,name); 
strcpy (filename ,"/usr/work/fharris/3 t_data/" ); 
strcat( filename 4 iame); 
strcat(filename,".3t"); 

/* open input file */ 

if((fdi=fopen( filename, "r")) < 0) 

{ 

printfC'cannot open fileO); 
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myworld[lat][longg-90] = NULL; 

) 

else 

{ 

/* set up input buffer *! 
if ((BUF=maUoc((buf_size )+l)) == NULL) 

I 

^rintf(stden:,"out of memoryO); 
myworld[lat][longg-90] = NULL; 

) 

setvbuf(fdi,BUF,_IOFBF,buf_size ); 

printfC before first read "); 

/* get lat long first 2 items in file */ 
fread(buf,2,2,fdi); 

/* make structure put pointer in world structure */ 
my world [lat] [longg-90] = make_levell(fdi); 

!* clean up */ 
fclose (fdi); 
free(BUF); 

) 

) 



ptrl make_levell(fdi) 
FILE *fdi; 



{ 

ptrl level; 
ptr2 ptr; 
int i,j; 

short bufiS 12], allzero; 



/* allocate stmcture */ 
level = (ptrl)ma!loc(sizeof(levell_rec)); 
/* loop through the level 2 data */ 
fread(buf,2,l,fdi); 
if(buf[0]==-l) 
level ->all_zero = TRUE; 
else 

I 

level->all_zero = FALSE; 
for(i=0;i<ll;i++) 
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for(j=0;j<ll;j++) 



level->level2ptr[i] [j] = mjike_le vel2(fdi,&(level->level2val [i] [j] )); 

} 

) 

retum(level); 

) 

ptr2 make_level2(fdi, value) 

FILE *fdi; 
short *value; 

I 

ptr2 level; 
ptr3 ptr; 
int s,t; 
short min; 
short allzero; 



fread(value,2, 1 ,fdi); 
if (*value = -1) 

{ 

*value = 0; 
retum(NULL); 

) 

else if (*value = -2) 

I 

fread(value,2,l,fdi); 

retum(NULL); 



else 

( 

/* allocate level2 data record */ 
level = (ptr2)malloc(sizeof(level2_rec)); 

/* loop through getting level 3 data */ 
for(s=0;s<ll;s-H-) 
for(t=0;t<ll;t++) 

I 

level->level3ptr[s][t]= make_level3(fdi,&(level->level3val[s][t])); 

} 

) 

retum(level); 



ptr3 make_level3(fdi, value) 



FILE *fdi; 
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short * value; 

{ 

int u,v; 

level3_rec *level; 

fread(value,2, i ,fdi); 
if (*value == -1) 

{ 

*value = 0; 
retum(NULL); 

) 

else if (*value = -2) 

{ 

fread(value,2,l ,fdi); 
retum(NULL); 

) 

else 

( 

get data record for 3rd level */ 
level = (ptr3)nialloc(sizeof(level3_rec)); 
fread(level->data,2,169,fdi); 
retum(level); 

} 

) 






!* pass in lat/long \vill return filename */ 



name_conv(lat,longg,name) 
short latfongg; 
char name[10J; 

I 

/* assume all lats and longs are north and east respectively */ 
char c[2J; 



c[l]=’ 

name[l]=’ 

name[0] = (char)((lat/10)+48); 

c[0] = (char)((lat%10)+48); 

strcat(name,c); 

c[0] = ’N’; 

strcat(name,c); 

c[0] = (char)((longg/100)+48); 

strcat(name,c); 

longg=longg%100; 
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c[0] = (char)((longg/10)+48); 
strcat(name,c); 

c[0] = (char)((longg%10)+48); 

strcat(name,c); 

clO] = ’E’; 

strcat(name,c); 

printf(" %s",name); 

) 
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* FnName: Draw_cell 

* Author: FRANK HARRIS 

* Purpose: Draws on e cell of terrain based on the 

input parameters.s version uses tlie 
pointer data structure 

draw_cell(cell,lat ,longg,max lx,min 1 x,max 1 z,min 1 z, 
max2x ,min2x 4 nax 2 z,min 2 z, 
max3x,min3x^ax3z,min3z) 
short cell,lat,longg; 
int maxlx,minlx,maxlz,minlz; 
int max2x,min2x,max2z,min2z; 
int max3x,min3x,max3z,min3z; 

I 

int maxsub2x,maxsub2z,minsub2x,minsub2z;/* overlap bounds */ 

int maxsub3x,maxsub3z,minsub3x,minsub3z; 

int stxl,stzl,spxl,spzl;/* start stop points for dif resolutions */ 

int stx2,stz2,spx2,spz2; 

int stx3,stz3,spx3,spz3; 

int i,j,s,t,u,v,count; 

ptrl ptr; 

ptr2 cptr; 

ptr3 sptr; 

/* get cell record */ 

if ((ptr = myworld[lat][longg-90]) == NULL) 

{ 

get_terrain(lat,longg); 

ptr = m>'world[lat][longg-90]; 

) 

if(ptr!=NULL) 

I 

/* adjust bounds depending on what cell were drawing */ 
adjust_bounds( 1 0,cell,&max 1 x ,&min 1 x ,&max 1 z,&min 1 z); 
adjust_bounds(100,cell,&max2x,&inin2x,&max2z,&min2z); 
adjust_bounds(1200,ceU,&max3x,&min3x,&max3z,&min3z); 

/* calculate overlap boundaries */ 

maxsub2x = max2x/10;/*level2 boundary with level 1. in level 1 coord */ 
maxsub2z = max2z/10; 
minsub2x = min2x/10; 
minsub2z = min2z/10; 
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maxsubSx = max3x/i2;/*level3 boundary with level2. in level2 coord */ 
maxsub3z = max3z/12; 
minsub3x = min3x/12; 
ininsub3z = min3z/12; 

/* adjust so will draw correctly when looking south and west */ 

/* stops the loop from accessing out of the array */ 
if(maxlx=10) 
maxlx = 9; 
if(maxlz=10) 
maxlz = 9; 

count = 0; 

/* draw level 1 area with aU three resolutions */ 
for(i=minl x;i<=max 1 x;i++) 
for(j=min lz;j<=max 1 z;j++) 

{ 

if((i>=minsub2x)&&(i<=maxsub2x)&&(j>=minsub2z)&&(j<=maxsub2z)) 
/* in level 2 area,draw level2 resolution */ 

I 

cptr = ptr->level2ptr[i][J]; 
if(cptr!=NULL) 

{ 

for(s=0;s<10;s++) 

for(t=0;t<10;t++) 

I 

if((((i* 1 0)+s)>=minsub3x)«&&(((i* 1 0)+s)<=maxsub3x)&& 

(((J * 1 0)+t)>=minsub3z)&&(((j* 1 0)+t)<=maxsub3z)) 

/* check if overlap level3 data draw level 3 resolution*/ 

{ 

sptr = cptr->level3ptr[s][t]; 
if(sptr!=NULL) 

I 

for(u=0;u< 1 2;u++) 
for(v=0;v<l 2;v++) 

I 

make_poUy( (u+v)%2, 

((i*CELL_SIZEl)+(s*CELL_SIZE2)+(u*CELL_SIZE3)), 
-((j*CELL_SIZEl)+(t*CELL_SIZE2)+(v*CELL_SlZE3)), 
sptr->dat a[u] [v] ,spt r->dat a[u] [v+ 1 ] , 
sptr->data[u+ 1 ] [v+ 1 ] ,sptr->data[u+ 1 ][v] , 

CELL_SIZE3); 



I 
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else 

/* draw level 2 resolution */ 

{ 



make_polly( (s+t)%2,(i*CELL_SIZEl+s*CELL_SIZE2), 
-(j*CELL_SIZEl+t*CELL_SIZE2), 
q)tr->level3val[s][t],cptr->level3val[s][t+l], 
q)tr->level3 val[s+ 1 ] [t+ 1 ] ,cptr->level3 val [s+ 1 ][t] , 
CELL SIZE2); 



) 

/* to cover up diffrences in resolution boundaries 
don’t need between level 1 and 2 too far to be noticeable */ 
if((((i*10)+s)==minsub3x)ll(((i*10)+s)=(maxsub3x))) 

{ 

draw_skirt(((i*10)+s),-((j*10)+O»cptr->level3val[s][t], 
( (i * 1 0)+s ) ,-((j * 1 0)+t+ 1 ) ,cptr->level3 val [s] [t+ 1 ] , 
CELL_SIZE2); 



) 

tf((((j*10)+t)=minsub3z)ll(((j*10)+t)=(maxsub3z))) 

{ 

draw_skirt(((i*10)+s),-((j*10)+t),cptr->level3val[s](t], 
((i* 1 0)+s+ 1 ),-((j * 1 0)+t) ,cptr->level3val [s+ 1 ] [t] , 
CELL_SIZE2); 

) 

) 



) 

else 

/* draw level 1 resolution */ 

{ 

count = count + 1; 

make_polly((i+j)%2,(i*CELL_SIZEl ),-(j*CELL_SIZEl ), 
ptr->le vel2val[ij [j] ,ptr->level2val [i] [j+ 1 ] , 
ptr->le vel2val[i+ 1 ] (j+ 1 ] ,ptr->level2valf i+1 ] {j ] , 
CE1.L_SIZE1); 

) 

)/* level 1 area *! 

}/* if cell has value */ 
printfC polly count %d ", count); 

) 
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